From: scott b. <sil...@ya...> - 2007-08-29 20:36:51
|
One could make some great portamento stuff with the slide function on the triple osc. --------------------------------- Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. |
From: Tobias D. <tob...@gm...> - 2007-08-30 06:25:33
|
Am Donnerstag, 30. August 2007 00:39:02 schrieb Paul Giblock: > Thats fine. But let's say I have two keys pressed, and then I > release both and press a new key. Which one of the two original notes > does the new note slide from? The lb302 has to do alot of really > funky things with silencing noteplayhandles, and storing the state of > all the variables on each frame, just so we can resume from the last > note when I new key is pressed. It has to do with how LMMS manages > buffers on overlapping notes. > > Anyways, it sounds cool, but I wouldn't want to write it :) Hm, I think one time we could move lot of code from lb302::playNote(...) to= =20 the instrument-API (i.e. a function stateResumePos() or things like that) s= o=20 it'd be rather easy to realize - not that I fundamentally want to change=20 TripleOsc & Co but one could add a switch "monophonic" to the=20 chord/arpeggio-tab (as in FL Studio) which would enable simple monophonic=20 behaviour. Will deal with that later. @Paul: when responding to someone on the list please *always* send it to th= e=20 list instead of the person (or keep the person in Cc). toby > -Paul > > On 8/29/07, Andre Lewis <an...@sp...> wrote: > > Why the next note pressed of course, using portamento time / rate to > > dictate the effect. I don't reckon it has to be perfect, in fact a > > little quirky is ok. > > > > Actually illogical behavior is one of the key factors to having people > > use software in ways the designers never anticipated. Lord knows Roland > > never expected their little guitar helper bass synth to work for anyone > > but the guitarist. Now of course it's impossible to keep them from > > adding a TB303 clone to their default sound-set. > > > > Andre Lewis > > > > On Wednesday 29 August 2007 01:51:12 pm Paul Giblock wrote: > > > Well, I think the big problem is that 3xOsc is Polyphonic. So, which > > > notes are supposed to slide where? > > > > > > -Paul > > > > > > On 8/29/07, scott belden <sil...@ya...> wrote: > > > > One could make some great portamento stuff with the slide function = on > > > > the triple osc. > > > > > > > > > > > > ________________________________ > > > > Park yourself in front of a world of choices in alternative vehicle= s. > > > > Visit the Yahoo! Auto Green Center. > > > > > > > > > > > > -------------------------------------------------------------------= =2D- > > > >---- This SF.net email is sponsored by: Splunk Inc. > > > > Still grepping through log files to find problems? Stop. > > > > Now Search log events and configuration files using AJAX and a > > > > browser. Download your FREE copy of Splunk now >>=20 > > > > http://get.splunk.com/ > > > > _______________________________________________ > > > > LMMS-devel mailing list > > > > LMM...@li... > > > > https://lists.sourceforge.net/lists/listinfo/lmms-devel > > > > > > ---------------------------------------------------------------------= =2D- > > >-- This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a browse= r. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > LMMS-devel mailing list > > > LMM...@li... > > > https://lists.sourceforge.net/lists/listinfo/lmms-devel =2D-=20 =46reiheit statt Angst -- Stoppt den =DCberwachungswahn! Demo in Berlin, Samstag 22.09.2007 www.freiheitstattangst.de |
From: Javier S. P. <ja...@te...> - 2007-08-30 06:48:55
|
Could someone remind me what's wrong with the current slide system? |
From: Tobias D. <tob...@gm...> - 2007-08-30 12:03:18
|
Hi, Am Donnerstag, 30. August 2007 08:48:45 schrieb Javier Serrano Polo: > Could someone remind me what's wrong with the current slide system? What you mean is not an actual "slide", it's a coarse per-note-detuning (wh= ich=20 only changes once per period!). When sliding, you want a contiguous=20 sample-exact change of frequency - like the sirene of the police in some=20 countries ;-) furthermore real slide is not done by drawing some=20 automation-stuff. Instead it's more or less a task of the (monophonic) synt= h=20 to provide smoooooooooooth slides. Do you see the difference? For this=20 plugins do not have to evaluate the frequency once per period, instead they= =20 have to do that inside the inner "buffer-filling-loop". toby =2D-=20 =46reiheit statt Angst -- Stoppt den =DCberwachungswahn! Demo in Berlin, Samstag 22.09.2007 www.freiheitstattangst.de |
From: Javier S. P. <ja...@te...> - 2007-08-31 07:10:51
|
El dj 30 de 08 del 2007 a les 13:04 +0200, en/na Tobias Doerffel va escriure: > Hi, > > Am Donnerstag, 30. August 2007 08:48:45 schrieb Javier Serrano Polo: > > Could someone remind me what's wrong with the current slide system? > What you mean is not an actual "slide", it's a coarse per-note-detuning (which > only changes once per period!). Once per 1/64 tact actually, unless it's shorter than a period. When it's done once in a period with "frequency smoothing", I can't notice the difference. This requires less CPU and plugin code changes are minimal. > When sliding, you want a contiguous > sample-exact change of frequency - like the sirene of the police in some > countries ;-) furthermore real slide is not done by drawing some > automation-stuff. Instead it's more or less a task of the (monophonic) synth > to provide smoooooooooooth slides. I disagree. There are many complex slides, not restricted to semitones. But you can show a special automation view with a particular slide type. All these can be improved through automation. Are you interested in future improvements in the current "slide" system? Bye. |
From: Paul G. <dr...@gm...> - 2007-08-29 20:51:18
|
Well, I think the big problem is that 3xOsc is Polyphonic. So, which notes are supposed to slide where? -Paul On 8/29/07, scott belden <sil...@ya...> wrote: > > > One could make some great portamento stuff with the slide function on the > triple osc. > > > ________________________________ > Park yourself in front of a world of choices in alternative vehicles. > Visit the Yahoo! Auto Green Center. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > > |
From: Andre L. <an...@sp...> - 2007-08-30 05:59:00
|
Excellent job on the latest version! I was having a discussion with one of my long time synth buddies who has worked extensively with a variety of sequencers / DAW's and we got into talking about why Pro-Tools audio always sounded better than everyone else's. He was of the opinion that it had to do with the digital summing and the internal bit depth. I've always believed it to be a function of the sound card and the pre-amps used, but his comment made sense. I have been wondering about that for LMMS, what is the internal processing of LMMS? If it's not allready I would hope for something like a 64/128 bit internal mixing engine. I was also wondering about a plug in type for basic tempo based LFO's that could be patched to all the automateable parameters on the system. Kind of like a mix between the fruity formula controller in FL, and an LFO generator that could be patched via some sort of matrix parameter automation. Sound like a good idea? Just thinkin, Andre On Wednesday 29 August 2007 01:36:34 pm scott belden wrote: > One could make some great portamento stuff with the slide function on the > triple osc. > > > --------------------------------- > Park yourself in front of a world of choices in alternative vehicles. > Visit the Yahoo! Auto Green Center. |
From: Tobias D. <tob...@gm...> - 2007-08-30 11:19:44
|
Am Donnerstag, 30. August 2007 07:58:46 schrieb Andre Lewis: > Excellent job on the latest version! > > I was having a discussion with one of my long time synth buddies who has > worked extensively with a variety of sequencers / DAW's and we got into > talking about why Pro-Tools audio always sounded better than everyone > else's. He was of the opinion that it had to do with the digital summing > and the internal bit depth. > > I've always believed it to be a function of the sound card and the pre-am= ps > used, but his comment made sense. > > I have been wondering about that for LMMS, what is the internal processing > of LMMS? If it's not allready I would hope for something like a 64/128 b= it > internal mixing engine. Currently it uses standard 24-bit-float which can be changed easily by=20 changing definition sample_t in include/types.h. Don't know whether this=20 really helps something. > I was also wondering about a plug in type for basic tempo based LFO's that > could be patched to all the automateable parameters on the system. Kind > of like a mix between the fruity formula controller in FL, and an LFO > generator that could be patched via some sort of matrix parameter > automation. Also had this idea already but currently we're busy with porting LMMS to Qt= 4=20 and make it work properly (see other mail from me a few days ago). toby =2D-=20 =46reiheit statt Angst -- Stoppt den =DCberwachungswahn! Demo in Berlin, Samstag 22.09.2007 www.freiheitstattangst.de |
From: danny m. <khj...@ya...> - 2007-08-31 00:16:47
|
> talking about why Pro-Tools audio always sounded > better than everyone else's. In my experience, the primary reason Pro-Tools sounds better is because the output is usually being monitored through very expensive speakers in a room that has been specifically designed for listening to music :) > He was of the opinion that it had to do with the > digital summing and the internal bit depth. Actually, as best I can remember, Pro-Tools offered the options of storing the tracks using 16 or 24 bit samples, which never really made much sense. I assumed it was working with 32 bits internally, then dithered it down to 24 when it wrote it to the disk (there's usually a bit of spectral weirdness in Pro-Tools files above 20k, which looks suspiciously like a dithering artefact). But whether or not it was working at 24 or 32 bits internally, the superior sound wasn't due to a higher bit resolution than other DAWs. I, too, suspect the Digidesign DSPs have something to do with it. > I have been wondering about that for LMMS, what is > the internal processing of LMMS? Many, many moons ago, I went through LMMS and tried to make sure that all of the processing was taking place using 32 bits. At that time, it was using a mixture of 32 and 64 bit calculations, and the implicit recasting of the variables and parameters was eating up a lot of CPU--especially in the oscillators. > If it's not allready I would hope for > something like a 64/128 bit internal mixing engine. At the moment, the biggest hindrance to increasing the bit depth is the effects--LADSPA and VST use 32 bit protocols. Danny ____________________________________________________________________________________ Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz |
From: Paul G. <dr...@gm...> - 2007-08-31 13:35:33
|
And then, aren't all the operations performed in 40bit or 80bit on the FPU? -Paul On 8/30/07, danny mcrae <khj...@ya...> wrote: > > > talking about why Pro-Tools audio always sounded > > better than everyone else's. > > In my experience, the primary reason Pro-Tools sounds > better is because the output is usually being > monitored through very expensive speakers in a room > that has been specifically designed for listening to > music :) > > > He was of the opinion that it had to do with the > > digital summing and the internal bit depth. > > Actually, as best I can remember, Pro-Tools offered > the options of storing the tracks using 16 or 24 bit > samples, which never really made much sense. I > assumed it was working with 32 bits internally, then > dithered it down to 24 when it wrote it to the disk > (there's usually a bit of spectral weirdness in > Pro-Tools files above 20k, which looks suspiciously > like a dithering artefact). > > But whether or not it was working at 24 or 32 bits > internally, the superior sound wasn't due to a higher > bit resolution than other DAWs. I, too, suspect the > Digidesign DSPs have something to do with it. > > > I have been wondering about that for LMMS, what is > > the internal processing of LMMS? > > Many, many moons ago, I went through LMMS and tried to > make sure that all of the processing was taking place > using 32 bits. At that time, it was using a mixture > of 32 and 64 bit calculations, and the implicit > recasting of the variables and parameters was eating > up a lot of CPU--especially in the oscillators. > > > If it's not allready I would hope for > > something like a 64/128 bit internal mixing engine. > > > At the moment, the biggest hindrance to increasing the > bit depth is the effects--LADSPA and VST use 32 bit > protocols. > > Danny > > > > ____________________________________________________________________________________ > Luggage? GPS? Comic books? > Check out fitting gifts for grads at Yahoo! Search > http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > |
From: danny m. <khj...@ya...> - 2007-08-31 23:59:25
|
> And then, aren't all the operations performed in > 40bit or 80bit on the FPU? There are a whole hodge-podge of register sizes available for floating point operations nowadays ranging from 32 bit to 128 bit (I think the 40 bit registers have been abandoned, but I'm not entirely sure about that--I'm pretty sure the 80 bit registers are still there). However, the limiting factor is going to be predominantly influenced by the size of the sample in memory. For example, the sequence for setting the volume in LMMS is something like: load a 32 bit sample load a 32 bit volume perform an 80 bit multiply store a 32 bit result So the truncation errors will still occur despite increased accuracy of the of the operation, which would seem like an argument in favor of increasing the bit depth of the sample. In testing (on a 64 bit OS), I wasn't able to tell the difference in processing speed between using 32 or 64 bits. Apart from the fact that the effects processing will be done at 32 bits, my long winded rationale for trying to standardize things on 32 bits is as follows: The argument against a huge bit depth is physiological. The comfortable dynamic range of human hearing is somewhere around 90dB, which is why that's a typical spec found in audio equipment. Each additional bit in a sample doubles the dynamic range of signal that can be represented--gives you another 6dB of headroom, so a 16 bit signal has a 96dB dynamic range, a 32 bit signal has a 192dB dynamic range, and a 64 bit signal has a 384dB dynamic range. Rounding errors are theoretically the same as adding 6dB of white noise to the signal. White noise doesn't sum constructively, so, in theory, 16 bits "should" be enough to prevent the errors from becoming audible. However, when mixing 20 tracks of music, there is often enough correlation in the errors between the tracks to result in 12dB of "noise" being added in. This reduces the dynamic range of the signal to 84dB, and it's entirely possible you have your stereo turned up loud enough to start hearing the errors in quiet parts of the song (you'll definitely hear it if you put on headphones). Now then, if you had a 32 bit D/A in your sound card and a sound system capable of reproducing a 196dB dynamic range, and you turned it up loud enough to be able to hear the extra 12dB of noise, the atmospheric pressure emanating from your speakers during the loud parts of the song would be capable of bursting enough cell walls in your body to reduce you to a quivering, oozy lump of something very dead. In other words the noise resulting from errors in 32 bit processing isn't likely to ever be perceivable. If you compose a song with 2000 tracks, it might start to become a problem again, but in most situations, the 384dB range allotted by 64 bits is a bit of overkill. Danny ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ |