i see,
thanks
anybody??? 😕
@adimatis wrote:
…They were long ago identified and they haven’t change much…
i would NOT bet on this …
needs are without doubt subject to change…and priorities aswell
ymmv
just to make it clear : this is ONLY MY point of view – if you don’t agree your welcome to
@CymaticCycle wrote:
…But speaking of polls, it will be most efficient if Frits himself creates a Thread dedicated to FR polls only…
i beg to differ – if everybody follows a very strict naming convention and creates a poll for every single request with always 3 choice ( yes / no / don’t know ) it should be very easy for Frits to identify what the users request and by having a poll for each request he can decide whether a reasonable bunch of users wants a certain feature ( read : must have ) or not ( nice to have )…
just my 2c
yes, that was me suggesting a kind of poll…
my idea was that Frits holds the poll so he can decide which features he wants to inplement and let us vote for most wanted ones.
another suggestion would be :
everbody posts one thead per request and adds a polling option with 3 choices : a) i would use this feature b) i would not use this feature c) i don’t know
i’ll add a thread as kind ox example
i still vote for single requests tbh!
that way Frits could compile a list with requests he does support and see fit AND then i’d still would be happy to have a poll to determine which requests are kind of common…
#1 : provide a humanize velocity function in the very same way it is possible with note positions.
#2 : make ANY menu entry available as ( at least hardcoded ) keyboard shortcut.
#3 : MIDI routing.
@The Telenator wrote:
…MIDI. It’s coming. It’s up there high on the list of guaranteed improvements…
@Zynewave wrote:
…It’s not on the top of the todo-list, so I can’t say when it will arrive…
where did you get this guarantees from, if i may ask?
so what happened to the list with 50+ request you had bookmarked?
getting some basic features done would be more pressing, wouldn’t it?
btw : AirDisplay does a tremendous job in supplying touch input to Podium …
@infinitoar : you do realize that i included 2 suggestions for usefull gadgets, do you?
and i still stand my ground that there is no difference in latency between a mic and a line in on the very same soundcard ( preamping the mic signal is not done by your computers cpu but some electronics onboard of the soundcard )…
in fact it’s this Telenator dude trolling around and accusing wrong people …
as i’m said to be the trouble maker i removed the link in my previous post…
@The Telenator wrote:
…Weren’t you the user in that other thread that was getting Podium’s “Mix” metering numbers at the bottom right corner of Arranger view confused with the PC’s CPU rate?
not sure what you are refering to? i take it as bad mouthing because i gotcha 😉
@The Telenator wrote:
You want me to “proof” [sic] it for you, michi? Really? Okay.
The MIC IN is really no different than the imput of a guitar amp. It can be anywhere from 50 to, oh, about 80mV — that’s millivolts. Fortunately, PCs work at very low voltage, but you still need to alter the signal to whatever level the computer wants to see. Add a treble boost or other boost, such as a distortion box, into the chain and who knows what voltage we are then dealing with! So, aside from the PC having to deal with conversion of an analog signal into digital, there are now potentially heavy voltage issues for it to deal with. More work.
Now, in the case of a LINE IN, we are usually dealing with a -20dB jack or a similar animal. Guitar amps often have these in the form of a line in to send a preamp signal from another amp into the amp with line in, direct to the power amp stage and/or a send/return loop for effects or other uses. These are normally hotter, somewhat more balanced affairs. It’s not as heavily affected by some fuzz box added to the chain. This also explains why putting the common floor pedal effect into the send/returns loop without a “volume” adjustment or line level control as were common on earlier amps, will overload that device, creating bizarre results — unwanted distortion, popping sounds, and possibly even frying the effect pedal.
Again, the PC will have to deal with voltage issues from a line in, but ideally, since the line in’s value is set by the PC designer, it should be a value that the PC wants to “see.” No guarantees, of course, but theoretically this is supposed to be what happens. Therefore, by using line in, infinitoar should be bypassing at least one stage of signal modification. There’s simply no telling what is destined for a Mic In signal (volume mixer, voice or music enhancement, EQ, who knows?) without looking at his computer’s specs, but it is safe to assume that line is should be more direct. That’s why it’s called a “line in,” michi.
The whole point is that the more processing and signal shaping required, the more work a PC has to do — a real no brainer. Does it also mean lower latency for line in? Again, who knows, but, yes, maybe. Read my posts more carefully: That’s why I stated, “Line in may be better for lower latency,” as opposed to a mic in. Perhaps you missed that disclaimer in my post — I said, MAY — but all of this is worth explaining anyway. HILARIOUS? Yes, in the sense that I would have assumed you were already familiar with how all this stuff works. I normally only need to explain things like this to folks who are pretty new to digital recording. Weren’t you the user in that other thread that was getting Podium’s “Mix” metering numbers at the bottom right corner of Arranger view confused with the PC’s CPU rate?
ah, now it’s clear – but how does procesing a line input differ from processing a mic input in terms of latency given approriate jacks on the very same sound card???
i really like the way you get pissed 😆 😆 😆
was a matter of copy and paste :
link removed
nice finding btw