Runaway CPU / Polyphony / Denormal Problem ?

jorge · 8 Mar 2005

Hi ik_ik_ik, that's a very long post for me to be answering now at 1:26 am, it's great feedback and I'll do my best. I think we might need to take it in steps and your help would be greatly appreciated.

First thing I suggest is that you try our latest internal version that you can download from: [old link] or: [old link] This is an internal version that is not ready for a normal release, it also has many new alpha and beta components, specially many of the alpha components might not work as they should and even file format might change.

At this stage it would be very useful to know if version 0.9.1c solves the problems you're having but I'll continue with this reply assuming it doesnt.

ik_ik_ik wrote: Simply create a looping pattern of short notes, set it to play and after a short time (around a minute) the CPU load starts to slowly rise until ultimately it hits maximum (after a few minutes). I'm using EnergyXT as a rule.

I tried it inside FLStudio with the example synth exported from v0.9.1c and didnt have the problem you mention. If you still have it with v0.9.1c I'll investigate if further. Also if needed I'll explain/investigate the current allocation of voices as the whole thing might be affected by the actual looping pattern you created.

ik_ik_ik wrote: Can anyone confirm this? What's going on? Is there a simple explanation?

I cant confirm it yet. The first explanation I can think of is a bug causing notes not to be released.

ik_ik_ik wrote: I'm using a 1.6GHz Centrino - may be relevant if the explanation is instruction set related.

That's very useful information, I also have a 1.6GHz centrino which is handy to compare results. With a Pentium M you shouldnt have denormal problems. I'm assuming you're using Windows XP like me.

ik_ik_ik wrote: How is the end of a note's processing determined given there's no apparent polyphony limit?

I dont see how polyphony limit is related to the end of a note's processing. Basically, a process is tagged for deleting N samples after noteOff with N=release. Due to SSE voices are grouped in 4 voices per sound process, the whole sound process is deleted when the 4 voices are tagged for deleting. A new voice will use one of the available free voices whenever possible.

ik_ik_ik wrote: It's also not entirely clear to me how the oscilators and ADSRs function and this I suspect is part of the problem too.

Ok, I'll go more into detail if the problem persists with v0.9.1c or even if you just want to know how it works.

ik_ik_ik wrote: sound starts with NOTE ON and stops with NOTE OFF - the oscillators are not free running but triggered/gated by MIDI input despite there being no VCA

I still think that's the correct way. The poly section of your synth will create a new voice per note played, when you dont have any notes playing, there should be no free running oscillators, that doesnt make sense to me. To have free running oscillators you connect them straight to the mono section without going through a PolyToMono. The PolyToMono basically adds all the notes being playing into one Mono channel, but if there are no notes playing, there's nothing to add. If it still doesnt make sense to you lets discuss it further.

ik_ik_ik wrote: But, when an ADSR is used, seemingly *anywhere* in the structure, with hold true and some release time then it's as if all the oscillators' behaviour changes and they are more like free running.

I'm assuming you mean in a poly section before a PolyToMono, in that case the hold=true causes the sound process to hold on until at least N samples after NoteOff with N=release. Otherwise the process is deleted at NoteOff which for a VCA is too early. The reason for that is that you normally have one ADSR that needs to hold the process until the release stage is finished but most other ADSRs dont, like for example a filter ADSR doesnt need to hold the process, the filter ADSR might have a very long release but once the main VCA ADSR gets to zero, there is no point in keeping that sound process alive.

ik_ik_ik wrote: Presumably this is a consequence of the underlying architecture (and lack of evident polyphony limit) but it's counter-intuitive - oscillators don't seem to run freely and their behaviour seems to depend on *other* elements in the structure.

It is intuitive to me, let's try to discuss it until it is intuitive to both of us. Oscillators do run freely in the right situation, when not part of a poly section.

ik_ik_ik wrote: Incidentally why does it take a couple of minutes at 100% CPU for the wave tables to be calculated every time SynthMaker is started? This isn't a slow machine. What is the process doing anyway? The application seems to work fine whilst this is happening.

It takes 15 sec on my machine which is also a 1.6GHz centrino and it takes 4 sec when done inside an exported VSTi. Basically, it is calculating the sawtooth and triangle waves, each of them uses a 256x2K lookup table. Waves are calculated with any number of harmonics up to 255 so that the wave stays bandlimited as you move up in frequency. The algorithm for calculating is highly inneficient at the moment, it is very easy to make it a lot faster, it just didnt get done yet. Also you only need those tables when you're actually using the sawtooth or triangle oscillators so it will probably change to calculate them only when required, for example when you drag the first sawtooth osc to the schematic. The reason it works while calculating is because most of the lookup tables you'd be playing dont have many harmonics and they are calculated at a very initial stage, very low frequency notes would probably start working more towards the end of the calculations.

I better go to sleep now, its 2:07am take care and thanks for your comments

stefan · 8 Mar 2005

You could probably rule out denormal issues by removing the delay and the filters. I've had some quite bad denormal issues earlier in my synth design, but I took care of it by adding and removing small numbers to the signal here and there 🙂

lalo · 8 Mar 2005

hi guys!

i think the 'free running oscillator thing' IS am issue...a lot of synthesis algorythm may include the possibility that an oscillator is NOT triggered by a note....for example LFO as ik said. Actually 'traditionally' synths works that way...the note on signal is simply a gate that open the output audio channel...note-off closes it. It should be related to VCA/ADSR things infact and not to oscillator... i know that from a coder's point of view this can seems strange...but not from a sound-designer's side. The osc can have a 'sync' inlet to be triggered by a gate signal so it is intitialized form it's current choosen phase angle (wich can be 0 to..so it starts from beginning) In this area fall the ppq thing i managed to talk about with jorge regarding the VSTtimeInfo component (alfa state or beta maybe 🙂 ) sometimes you want an LFO or other signals not to be linked to the note-on event...but just free running...and even locked to the song's bpm/time signature. anyway this is a very imortant and interesting topic..cause i think is goin' to the core of SM 🙂 i'll try the 0.9.1.c with energyXT to see if i have the same problem... can it be related to the playing loop in eXT ending before a note-off?

love to you all 🙂

lalo

stefan · 8 Mar 2005

You can make the oscillator run freely by using time info or samplepos. The oscillator won't be calculated when the voice is free, but you can still use the samplepos to calculate the phase of the oscillator. All this free/synced stuff is doable by using time info / samplepos. So it's not an issue really. Just make a non-triggered oscillator and share it with everyone 🙂

lalo · 8 Mar 2005

stefancrs wrote: You can make the oscillator run freely by using time info or samplepos. The oscillator won't be calculated when the voice is free, but you can still use the samplepos to calculate the phase of the oscillator. All this free/synced stuff is doable by using time info / samplepos. So it's not an issue really. Just make a non-triggered oscillator and share it with everyone 🙂

😀 oh if ony i were a coder 🙂 ..i'm after to learn some after your work is released 🙂 then i'll do some bits for sure... isn't samplepos more cpu-intensive of ppq/time-signature? just to do (say) an LFO wich goes at (say) 1 dotted quarter but isn't retriggered everytime i hit a note...but continues its run...freely..

..but what about the osc/adsr thing? that topic is more 'deep'..it has to do with SM architecture i guess...

lalo

stefan · 8 Mar 2005

lalo wrote: stefancrs wrote: You can make the oscillator run freely by using time info or samplepos. The oscillator won't be calculated when the voice is free, but you can still use the samplepos to calculate the phase of the oscillator. All this free/synced stuff is doable by using time info / samplepos. So it's not an issue really. Just make a non-triggered oscillator and share it with everyone 🙂

😀 oh if ony i were a coder 🙂 ..i'm after to learn some after your work is released 🙂 then i'll do some bits for sure... isn't samplepos more cpu-intensive of ppq/time-signature? just to do (say) an LFO wich goes at (say) 1 dotted quarter but isn't retriggered everytime i hit a note...but continues its run...freely..

..but what about the osc/adsr thing? that topic is more 'deep'..it has to do with SM architecture i guess...

lalo

Free running osc's can be made by using the calculated samplepos for the note on, and adjusting the phase of the oscillator accordingly. Since having triggered oscillators is the more basic/cleaner/faster solution, that should be the default imo.

Free running lfo's can be done by having them in a mono section instead of a poly section.

Atm, I don't have free running lfo's in my synth, but I will add them later on. My synth will most likely not be the best learning example due to its complexity, but the high level modules in it can be used for an educational purpose.

jorge · 8 Mar 2005

lalo wrote: i think the 'free running oscillator thing' IS am issue...a lot of synthesis algorythm may include the possibility that an oscillator is NOT triggered by a note....for example LFO as ik said.

I dont think its an issue. To be clear, what I'm debating is not that there should be a way to have free running oscillators, I think there should and actually there is already. The question is how to represent them in an intuitive graphical way. It's also not a consequence of SM's architecture but more a consequence of not being convinced that it should work in a different way. Like stefan said, you can do free running LFOs with the SamplePos component ( although it wasnt in version 0.9.1a and it needs documentation on how to use it ), you can find it in version 0.9.1c as an alpha component. The Mono section before the sound goes to the sound card is constantly running. You will also have in the near future a MonoToPoly so that you can have free running sections connected to poly sections of the schematic.

The main point I'm making, please anyone feel free to make me think differently, is that an oscillator in a poly section of a schematic, should not generate any sound when there arent any notes playing.

lalo · 8 Mar 2005

stefancrs wrote: My synth will most likely not be the best learning example due to its complexity, but the high level modules in it can be used for an educational purpose.

i'll try to learn anyway 🙂 i'm talkin' about your code in code component...not the modular architecture i'm really excited about that..infact i use a lot your SVF wich i think is beautiful..go ahead man 🙂

lalo

lalo · 8 Mar 2005

jorge wrote: The main point I'm making, please anyone feel free to make me think differently, is that an oscillator in a poly section of a schematic, should not generate any sound when there arent any notes playing.

hi jorge! (how do you do?)

is often an hard task to...convince you.. as it an hard task to convince me 😉 but i like plato-like dialogues 🙂 and using socratic methods...

joke apart...maybe is a little and not important thing...i mean the old analogue synthesizer works that way (having free running oscillators and the VCA/ADSR triggered by keyboard gate/trigger signals) so to do a strict analog emulation..can be needed...

but maybe is only a state of mind..i mean all the soft i used (pd/csound for instance) go that way, my korg MS10 go that way...so i don't wanna force you to do the same.. to me is more logical from a sound design point of view to have the kyboard to trigger the ADSR as default and the osc free running as default or synced if the sound designer need it.... but is only my humble opinion.

love lalo

ik_ik_ik · 8 Mar 2005

Wow, thanks guys for jumping in to what is becoming a fascinating thread!

Thanks Jorge for replying in so much detail so late. Much appreciated! I did read it last night too but thought I'd sleep on it.

I'm glad Lalo has joined in as I think we're coming at it from the same direction and I'd agree we are diving into the core of the application architecture. There is an evident divide between the architecture from a code point of view and traditional sound design one.

I'm afraid it's going to be another long post although I'll try to be clear.

I'm either missing some fundamentals or, there's some fundamentals missing 🙂 I suspect the first is more likely 😀

So, I was thinking that there are a couple of analogue synthesiser basics that I'll use to illustrate concepts where I'm struggling...

1. First example I want to describe is a free-running LFO to modulate an oscillator's frequency. The LFO is essentially a mono process, it applies to all voice processes. There is no need to have an LFO created for each note process, that's inefficient and the behaviour of the LFO will differ. There is a big difference between a dual oscillator synth (even one with a fixed frequency which could be considered like a poly LFO but it isn't) and a single oscillator synth that shares a common LFO across all it's voices (a far more common application of an LFO). I can't see how this would be achieved - yet. An LFO contunues to run even when no notes are active such that it's position remains continuous - the SamplePos approach that Stefan mentioned sounds promising.

I think this illustrates a conceptual problem regards the deliniation between Poly and Mono. I think the MonoToPoly that Jorge mentioned is one of the missing links. I guess we're maybe trying to run before we can walk and the "basic" analogue synthesizer model is not so basic after all 😉

2. I have to think that the CPU runaway problem must be related to problems in determining the end of a note process and releasing that process - without polyphony (i.e. process limit) runaway problems will be very hard to avoid). Common sense to me says that if N note processes start in the process length time (let's asume that's simply release time R) then the maximum polyphony that is used (process count) will be N and there can't be a situation that would runaway unless there are some very long or hung note processes. I've replicated the problem in EnergyXT as standalone and within MiniHost and also in Console using fairly simple 16th note arpeggio patterns of short 16th notes. Perhaps there's something odd about duplicate notes occuring - how are the processes handled in this case, perhaps there's a process allocation or stack issue, maybe hung note processes are somehow the result?

I'll go back to one of my original questions, what determines the end of the process? Or "the osc/adsr thing" as Lalo has called it 🙂 I'll use a second example...

Let's say I have a simple oscilator and its output level is modulated (poly multiplied) by an ADSR with hold true. OK, the level reaches zero after the release time R and the process should be released. Make sense.

So, let's say I have two ADSRs modulating the level and let's say they are both connected to the same terminal of the poly multiply (which I'm led to assume adds the signals - I've had issues with this not behaving as I'd expect but I'll raise that later). If they are both set to hold true and with different release times (I haven't tried this but assume it's possible). What determines the end of the process then?

Further, let's say I have an ADSR and an LFO modulating the level (tremolo). The ADSR may reach zero at the end of its release time R but the process's level will never reach zero unless the envelope modulation comes after the LFO modulation.

I think there's an assumption that a single "master" ADSR must modulate the level and it's position in the structure seems critical. There's an inherent way that the end of a note process is determined which is not clear. It seems very easy to produce something where that doesn't happen and without polyphony/process limiting (thus process stealing, allocation) then there are big problems in store.

I think Jorge's statement "an oscillator in a poly section of a schematic, should not generate any sound when there arent any notes playing" is logically correct but, the problem is what consitutes that a note *is* playing.

Does this make sense? It's hard work writing long message in this tiny textarea without losing the flow 🙂

I'm really trying to get my head around the basics and using the analogue synth model is a good place to start before getting carried away. I'm really really excited about getting stuck into the DSP and code stuff - that's a killer feature. Heh, I'll have to dust off a bunch of frequency domain and Fourier transform stuff though 😀

I'll have a look into 0_9_1c this evening if I get the chance.

Jorge, I hope I've explained better some of the issues. BTW yes, I'm using XP.

Cheers,

Inigo

stefan · 8 Mar 2005

Cutting away anything that I don't actually respond to 🙂

ik_ik_ik wrote: 1. First example I want to describe is a free-running LFO to modulate an oscillator's frequency. The LFO is essentially a mono process, it applies to all voice processes. There is no need to have an LFO created for each note process, that's inefficient and the behaviour of the LFO will differ. There is a big difference between a dual oscillator synth (even one with a fixed frequency which could be considered like a poly LFO but it isn't) and a single oscillator synth that shares a common LFO across all it's voices (a far more common application of an LFO). I can't see how this would be achieved - yet. An LFO contunues to run even when no notes are active such that it's position remains continuous - the SamplePos approach that Stefan mentioned sounds promising.

For just making something be a free running mono LFO you just have to make it part of a mono section instead of a poly section. Samplepos and time info ought to be used to sync stuff to the host.

ik_ik_ik wrote: I think this illustrates a conceptual problem regards the deliniation between Poly and Mono. I think the MonoToPoly that Jorge mentioned is one of the missing links. I guess we're maybe trying to run before we can walk and the "basic" analogue synthesizer model is not so basic after all 😉

Sure it is 🙂. The parts of it are fairly basic, it's just the sum of them that gets complex usually 🙂 the MonoToPoly will be a good addition though.

ik_ik_ik wrote: 2. I have to think that the CPU runaway problem must be related to problems in determining the end of a note process and releasing that process - without polyphony (i.e. process limit) runaway problems will be very hard to avoid). Common sense to me says that if N note processes start in the process length time (let's asume that's simply release time R) then the maximum polyphony that is used (process count) will be N and there can't be a situation that would runaway unless there are some very long or hung note processes. I've replicated the problem in EnergyXT as standalone and within MiniHost and also in Console using fairly simple 16th note arpeggio patterns of short 16th notes. Perhaps there's something odd about duplicate notes occuring - how are the processes handled in this case, perhaps there's a process allocation or stack issue, maybe hung note processes are somehow the result?

Did you try removing the delay and the filters? Because if there are denormal issues, they most likely reside in those components.

ik_ik_ik wrote: I'll go back to one of my original questions, what determines the end of the process? Or "the osc/adsr thing" as Lalo has called it 🙂 I'll use a second example...

Let's say I have a simple oscilator and its output level is modulated (poly multiplied) by an ADSR with hold true. OK, the level reaches zero after the release time R and the process should be released. Make sense.

So, let's say I have two ADSRs modulating the level and let's say they are both connected to the same terminal of the poly multiply (which I'm led to assume adds the signals - I've had issues with this not behaving as I'd expect but I'll raise that later). If they are both set to hold true and with different release times (I haven't tried this but assume it's possible). What determines the end of the process then?

Further, let's say I have an ADSR and an LFO modulating the level (tremolo). The ADSR may reach zero at the end of its release time R but the process's level will never reach zero unless the envelope modulation comes after the LFO modulation.

I think there's an assumption that a single "master" ADSR must modulate the level and it's position in the structure seems critical. There's an inherent way that the end of a note process is determined which is not clear. It seems very easy to produce something where that doesn't happen and without polyphony/process limiting (thus process stealing, allocation) then there are big problems in store.

I think Jorge's statement "an oscillator in a poly section of a schematic, should not generate any sound when there arent any notes playing" is logically correct but, the problem is what consitutes that a note *is* playing.

As far as I know the VCA module is the only thing that at the moment can keep a voice alive after the note has been released. You control this by setting its Hold input to "true".

Modulating the volume by adding values after the volume envelope seems to be a "stupid" thing to do, since even on an analouge synth, this would mean that a voice would never be finished. Always end the synths poly section with a VCA 🙂

ik_ik_ik · 8 Mar 2005

Hi Stefan and thanks for the reply 🙂

stefancrs wrote: Modulating the volume by adding values after the volume envelope seems to be a "stupid" thing to do, since even on an analouge synth, this would mean that a voice would never be finished. Always end the synths poly section with a VCA 🙂

Exactly! And it's far from stupid - in many cases such behaviour is very desirable. It's a feature of masses of synthesisers' architecture - from good old analogue electronics to software (I can think of numerous examples of the top of my head).

Using the analogue mono synth as an example you might well want to play a continuous tone with MIDI input providing pitch information but without triggering or having to have a "master" envelope that has to return to zero to release a process.

Note processes should, I feel, effectively be restricted by polyphony (or in Synth Maker terms a process count limit). Obviously this limit would be flexible.

I think the current approach leads to a lot of restrictions on the possibilities with Synth Maker. Long, or infinite, release times become extremely dangerous but are very, very useful and creative. I can think of many situations where I might want to have continuous sound - I'm certain I'm not alone here!

Jumping ahead a little and far beyond the simple analogue synth example, I might want to create a physical model such that a "resonator" is continuous and it is stimulated periodically by an "exciter" (triggered by a note or notes). The code/DSP stuff is going to be fun 😉

It's a fundamental difference of opinion perhaps but I think the case is serious here. It would be good to get some other opinions 🙂

stefancrs wrote: Always end the synths poly section with a VCA

Yes, that seems to be the inherent requirement. As well as that VCA falling to zero and being modulated exclusively by an ADSR. It does enforce a particular, and limiting, structure to anything Synth Maker can produce though.

Thanks for the engaging dialogue guys! I'm very keen to "early adopt" but I just see a few restricting problems not too far around the corner which are holding me back to be honest.

Cheers,

Inigo

lalo · 8 Mar 2005

ik_ik_ik wrote: Thanks for the engaging dialogue guys! I'm very keen to "early adopt" but I just see a few restricting problems not too far around the corner which are holding me back to be honest.

Cheers,

Inigo

me to like to have more opinions 'cause i feel is an important topic... but ik...just support SM if you can 🙂

my little SM advertising 🙂

lalo

stefan · 8 Mar 2005

ik_ik_ik wrote: Hi Stefan and thanks for the reply 🙂

stefancrs wrote: Modulating the volume by adding values after the volume envelope seems to be a "stupid" thing to do, since even on an analouge synth, this would mean that a voice would never be finished. Always end the synths poly section with a VCA 🙂

Exactly! And it's far from stupid - in many cases such behaviour is very desirable. It's a feature of masses of synthesisers' architecture - from good old analogue electronics to software (I can think of numerous examples of the top of my head).

Using the analogue mono synth as an example you might well want to play a continuous tone with MIDI input providing pitch information but without triggering or having to have a "master" envelope that has to return to zero to release a process.

Oh, for monophonic synths it's ok indeed. in SM you don't have to care about if a voice is playing or not if the synth is monophonic imo. I was totally thinking about polyphonic stuff, sorry.

ik_ik_ik wrote: Note processes should, I feel, effectively be restricted by polyphony (or in Synth Maker terms a process count limit). Obviously this limit would be flexible.

I think the current approach leads to a lot of restrictions on the possibilities with Synth Maker. Long, or infinite, release times become extremely dangerous but are very, very useful and creative. I can think of many situations where I might want to have continuous sound - I'm certain I'm not alone here!

Jumping ahead a little and far beyond the simple analogue synth example, I might want to create a physical model such that a "resonator" is continuous and it is stimulated periodically by an "exciter" (triggered by a note or notes). The code/DSP stuff is going to be fun 😉

It's a fundamental difference of opinion perhaps but I think the case is serious here. It would be good to get some other opinions 🙂

Monophonic or polyphonic resonators? But you are right though. It'd be good to be able to have a synth with for instance 1 minute release times on the voice, but still be able to play it normally without getting hundreds of active voices when you might just want four of them. A good place to put the "restrictor" might be in the poly2mono converter?

ik_ik_ik wrote: stefancrs wrote: Always end the synths poly section with a VCA

Yes, that seems to be the inherent requirement. As well as that VCA falling to zero and being modulated exclusively by an ADSR. It does enforce a particular, and limiting, structure to anything Synth Maker can produce though.

You can modulate the volume with anything you like, just as long as there somewhere in the polyphonic section is a VCA that can tell if the voice/process/channel is held or not.

ik_ik_ik · 8 Mar 2005

lalo wrote: but ik...just support SM if you can 🙂

my little SM advertising 🙂

Well, I think I will. No question the support is first rate but I want to be sure it will be genuinely flexible and unique too. I'm 95% sure already though.

And what a fun acronym it is too 😉 😀

ik_ik_ik · 8 Mar 2005

stefancrs wrote: Oh, for monophonic synths it's ok indeed. in SM you don't have to care about if a voice is playing or not if the synth is monophonic imo. I was totally thinking about polyphonic stuff, sorry.

I think you have to think of monophonic as simply being a special case of very limited polyphony though - from the point of view of what we're discussing.

stefancrs wrote: Monophonic or polyphonic resonators?

Well, why not 🙂 It's this kind of flexibilty that is very desirable. Maybe I want to model something that isn't feasible or practical in the real-world 😉

stefancrs wrote: But you are right though. It'd be good to be able to have a synth with for instance 1 minute release times on the voice, but still be able to play it normally without getting hundreds of active voices when you might just want four of them. A good place to put the "restrictor" might be in the poly2mono converter?

I think, to my way of thinking at least, it's something that would have to be part of the MIDI to P converter although possibly both that and the P to M? This is where the behind-the-scenes architecture starts to blur things again. It makes sense to me that polyphony would be managed at the point polyphony is "created" rather than "destroyed" but obviously the "cancellation" of note processes is effectively managed at the "master" VCA or P to M point in the structure.

stefancrs wrote: You can modulate the volume with anything you like, just as long as there somewhere in the polyphonic section is a VCA that can tell if the voice/process/channel is held or not.

But it's an ADSR not VCA that determines hold! The confusion is catching 😀 Although of course it relies on the "master" ADSR being connected to a poly multiply to act as a VCA at the end of the chain.

Cheers,

Inigo

stefan · 8 Mar 2005

ik_ik_ik wrote: stefancrs wrote: Oh, for monophonic synths it's ok indeed. in SM you don't have to care about if a voice is playing or not if the synth is monophonic imo. I was totally thinking about polyphonic stuff, sorry.

I think you have to think of monophonic as simply being a special case of very limited polyphony though - from the point of view of what we're discussing.

Ok 🙂

ik_ik_ik wrote: stefancrs wrote: But you are right though. It'd be good to be able to have a synth with for instance 1 minute release times on the voice, but still be able to play it normally without getting hundreds of active voices when you might just want four of them. A good place to put the "restrictor" might be in the poly2mono converter?

I think, to my way of thinking at least, it's something that would have to be part of the MIDI to P converter although possibly both that and the P to M? This is where the behind-the-scenes architecture starts to blur things again. It makes sense to me that polyphony would be managed at the point polyphony is "created" rather than "destroyed" but obviously the "cancellation" of note processes is effectively managed at the "master" VCA or P to M point in the structure.

Honestly, I think you're right and I was wrong 🙂 The destruction of a voice is of interest for the allocation of a voice ofcourse, but that's just a matter of internal voice management and should not be an issue for the users POV.

ik_ik_ik wrote: stefancrs wrote: You can modulate the volume with anything you like, just as long as there somewhere in the polyphonic section is a VCA that can tell if the voice/process/channel is held or not.

But it's an ADSR not VCA that determines hold! The confusion is catching 😀 Although of course it relies on the "master" ADSR being connected to a poly multiply to act as a VCA at the end of the chain.

Well. For some reason I thought the ADSR was called VCA, just because that's what it's "mother module" is named in the example file. My bad! Though, you don't have to use it as an ADSR, you can just use it as a gate or whatever. There's no such thing as a VCA and there really shouldn't be at this component level. There ought to be a component for just holding a voice though, that just have a gate/bool input.

ik_ik_ik · 8 Mar 2005

stefancrs wrote: Honestly, I think you're right and I was wrong 🙂 The destruction of a voice is of interest for the allocation of a voice ofcourse, but that's just a matter of internal voice management and should not be an issue for the users POV.

I guess there's not much to add on the issue. Well, I'm sure there is but it's been a heavy couple of pages of posts. There's been some really valuable and important ideas thrown around. Voice management has to be the way forward. Let's see where things go 🙂

stefancrs wrote: Well. For some reason I thought the ADSR was called VCA, just because that's what it's "mother module" is named in the example file. My bad! Though, you don't have to use it as an ADSR, you can just use it as a gate or whatever. There's no such thing as a VCA and there really shouldn't be at this component level. There ought to be a component for just holding a voice though, that just have a gate/bool input.

Hitting the nail on the head I think 🙂 I was often quite careful to write poly multiply rather than VCA but I think the point that's come up and clarified is that there are some assumptions inherent in the architecture that are limiting the scope of possibilites. OSC, ADSR, VCA interactions and voice allocation is at core and I think we've dug out some good ways forward which is great. Along with voice management a voice "container" would probably make a lot of sense from many angles.

Cheers,

Inigo

ik_ik_ik · 10 Mar 2005

I was just reading back through this topic and hmmm, quite deep stuff. Thanks again for the dialogue and I hope it's been helpful!

I've not had the chance to give 0_9_1c a road test yet but will get back to it as soon as I can 🙂

Cheers,

Inigo

lalo · 11 Mar 2005

yes very interesting and crucial indeed 🙂

when he'll have some time will be interesting to have a new intervention from jorge on this subject...he told me he'd like we all agree on this 🙂 ..but atm he and malc too are workin' hard planning a new release in the next days/weeks i guess 🙂

love lalo

ik_ik_ik · 12 Mar 2005

OK. Now that I've early adopted I've put a bit more effort into the runaway CPU issue that kicked off this thread. I've knocked together a fairly simple schematic as follows:

You can download the 0_9_1c based schematic [here].

It's a simple enough three oscillator synth sharing an ADSR between a pretty much static filter (based on the code filter in the example) and a poly multiplier (acting as a VCA). Both the level and cutoff are velocity sensitive. There's no GUI, it's a simple static example 🙂

As you can see in the above schematic the ADSR Hold is set to 0 (false) so there is no release phase. I've generated a VSTi in this state called ikTriSaw0.dll which you can download [here].

Then, having changed the ADSR Hold input to 1 (true), I've generated a second VSTi in this state called ikTriSaw1.dll which you can download [here]. The release time is by no means long in this example (as far as I understand it anyway).

To test I've set up a simple looping arpeggio in EnergyXT as follows:

I'm sure it'll be clear enough what's happening - especially for Lalo 🙂 A simple four note looping pattern of 16th notes that I then set to play at 140bpm. Not too strenuous I think 🙂

If I use the ikTriSaw0.dll VSTi then everything seems fine. The CPU idles at a constant low load ad infinitum.

If I use the ikTriSaw1.dll VSTi then things go wrong. After around 30 seconds the CPU load clearly starts to steadily rise. Ultimately reaching 100% after a couple of minutes and bringing the system to its knees. This is on a Centrino 1.6Ghz system running at full throttle.

As I mentioned at the start of the thread I've replicated the behaviour in a few different hosts so I'm fairly confident it's not an EnergyXT issue for example.

So, it would be great to a) confirm the problematic behaviour by the VSTi dlls and b) get some explanation as to what the problem might be occuring.

Hope this helps!

It's possible there's a flaw in my logic but I don't think that's the case. I've used this simple example but I do get the same behaviour happening with the example provided with Synth Maker. In fact basically any synth I've tried.

Incidentally I've used 0_9_1c - some nice new additions appearing to the palette of modules 😀

Cheers,

Inigo

jorge · 12 Mar 2005

Hi ik_ik_ik

Thanks for your very detailed bug report.

I downloaded your ikTriSaw1.dll VSTi and tried it inside FLStudio.

With the following pattern I was able to recreate the bug you describe:

Although with the following pattern everything was fine:

That indicates that the problem is related with the NoteOff of the last note never being received by the VSTi before looping. I assumed ( wrongly it seems ) that before looping, the VSTi would receive a NoteOff for each note still playing.

What's confusing me now is that the following pattern works fine too:

Anyway, that's a very good clue to where the problem can be. One way around it is probably to generate a NoteOff for all notes still playing when going back to the beginning of a loop. I'll have a look, could also be related with the host passing note duration rather than a note off.

ik_ik_ik · 12 Mar 2005

Hi Jorge,

Great, thanks for the reply! It's good to know I'm not alone with the problem.

I tried juggling some note lengths and positions too (at the start and end of the pattern in particular) but sounds like you're on the case 🙂 Yeah, weird how your third example works out ok!

As well as missing note offs as you describe I was wondering about any possible problems with retriggering duplicate notes that haven't fully released - as will of course be the case with such short looping patterns. I guess this kind of retriggering and missing note offs have quite a lot of overlap in this scenario anyway.

Looking forward to seeing what the clues turn up!

Cheers,

Inigo

Zynewave · 12 Mar 2005

Hi,

I tried the ikTriSaw0.dll and ikTriSaw1.dll in Podium, and set up play back as described with 16th notes etc. At first I did not notice the accelerating CPU problem, but I did notice that the notes were not played in steady sync. I was using an ASIO buffer size of 512. I tried increasing the buffer to 4096, and then the notes were all over the place. Lowering the buffer to 256 produced the accelerating CPU on my system as well, which is a P4 1.7 laptop.

If I were to take a wild guess, it seems that SM does not interpret the deltaFrames value correctly in the note events, and thus in certain situations notes on/offs may be processed in an incorrect chronologic order?

Frits

jorge · 12 Mar 2005

Hi Zynewave

Zynewave wrote: If I were to take a wild guess, it seems that SM does not interpret the deltaFrames value correctly in the note events, and thus in certain situations notes on/offs may be processed in an incorrect chronologic order?

You're correct, that was done in the old version of SM ( pre-new framework ) but didnt make it to the new one yet. Now that other things are feeling more complete, I guess deltaframes is becoming top priority.

I'm not sure if deltaFrames is related with the problem ik_ik_ik reported.

stefan · 12 Mar 2005

This is very similar to the denormal issues I used to have when using my own coded filters and the delay component earlier on. I solved it by doing some anti-denormal stuff within my filters (which I also have in the feedback path of the delay in my synth). If you remove the filter from the schematic, can you still get these problems?

jorge · 12 Mar 2005

Hi Stefan

stefancrs wrote: If you remove the filter from the schematic, can you still get these problems?

I didnt try yet but the problem ik_ik_ik reported builds up CPU useage a lot slower than denormals. It take me 30 loops of the pattern to get the CPU up to 20% and it keeps slowly increasing.

At the moment, I think ik_ik_ik's bug, denormals, and deltaFrames are all unrelated. Denormals ( as you know ) can already be sorted inside the schematic, DeltaFrames is a question of implementing it and the runaway issue needs fixing. I've done some fixing of bugs related with allocating sound processes to notes, I guess I'll try ik_ik_ik's schematic with the latest version in case the problem is fixed.

stefan · 13 Mar 2005

Oh, you're right. If the increase acts like that it sure as hell ain't denormals 🙂

Shifrin · 18 Mar 2005

Just a bump to say I'm having a similar problem with a VSTi I'm working on. I load it into my host (EnergyXT) and set it to loop playing a few notes, after several passes of the loop the CPU meter starts slowly going up and up, and up, and up!!!!!

Shif.

ik_ik_ik · 25 Mar 2005

Glad to know Shif has the same problem at least. So, just another little bump to see where things might be with the runaway issue?

Cheers,

Inigo

jorge · 25 Mar 2005

ik_ik_ik wrote: Glad to know Shif has the same problem at least. So, just another little bump to see where things might be with the runaway issue?

thanks ik_ik_ik and Shifrin

I'd just like to say that these bumps are very useful.

ik_ik_ik · 15 Apr 2005

Just another little useful bump as it's still happening (0.9.2n). Still with FM3x as well as my own schematics.

Along the lines of what Jorge posted on March 12th...

This pattern makes the CPU rise:

This pattern, with a space before the loop point, seems not to:

I've had a look at the pattern's MIDI output using Toby Bear's Kondor and all note ons and note offs seem to be present and correct but it looks like EnergyXT may well be sending note ons and a duration (not sure how to know exactly). Kondor seems to show a note on and its corresponding note off (a note on with 0 velocity) at the same moment in time but with a differing delta. Does this help? It seems to happen in a few hosts though so must be a generic issue.

Cheers,

Inigo

jorge · 15 Apr 2005

ik_ik_ik wrote: Just another little useful bump as it's still happening (0.9.2n).

Thanks, the bumping is very useful. I've just finished fixing some other important bugs, I consider this one to be number 1 priority now.

ik_ik_ik wrote: I've had a look at the pattern's MIDI output using Toby Bear's Kondor and all note ons and note offs seem to be present and correct but it looks like EnergyXT may well be sending note ons and a duration (not sure how to know exactly). Kondor seems to show a note on and its corresponding note off (a note on with 0 velocity) at the same moment in time but with a differing delta. Does this help? It seems to happen in a few hosts though so must be a generic issue.

Yeah, it helps a lot, thanks.

jorge · 18 Apr 2005

ik_ik_ik, I couldnt resist having a look at the Runaway CPU bug before going to sleep. I know already some improvements that need to be made to make Midi more efficient for exported VSTis but the following might sort the Runaway CPU bug for now: [old link]

ik_ik_ik · 18 Apr 2005

Thanks Jorge 🙂

I can't check it out just now but I'll certainly have a look this evening all being well.

Cheers,

Inigo

ik_ik_ik · 18 Apr 2005

Hi Jorge,

I've had a quick go with 0.9.3a - loaded up the good old ikTriSaw and also the latest example schematics and exported fresh VSTi DLLs for both.

Alas, the problem with creeping CPU load is still happening 🙁 It really looks like a problem with the last note hanging and spawning more and more processes as the loop cycles add up.

I had another idea to test out and it was a success...

Using a similar 4 beat looping pattern to test I set about editing the last of the four notes to see what happened.

First, I halved it's length from a full beat length of 240 to 120 "ticks" and the CPU stayed stable when looping this pattern. Then I doubled the tempo from 120bpm to 240bpm and the CPU creep started to happen again. Hmmm.

So, I tried the reverse situation, I made the last note have length of 180 "ticks" and at a tempo of 120 bpm the CPU creep happened. When I halved the tempo to 60bpm the CPU stayed stable.

My conclusion is that the issue is time related (and I'd have a stab at buffer size related). My hypothosis - when the note off is set later than the loop point minus a period related to the buffer size then the note off is lost and processes start to be spawned in error. This is starting to sound like the Script of the movie Pi 🙂 It's only a hypothesis though.

Maybe this is related to the Delta Frames point already mentioned?

BTW the ASIO output (0.9.3a) is working nicely over here with ASIO4ALL.

With Echo Indigo native ASIO drivers things are not so comfortable - horrible zipper noise and glitching connected with GUI activity much along the lines that a few of us suffer with EnergyXT (and very few other applications) as it happens!

Cheers,

Inigo

mathman · 18 Apr 2005

Sorry Jorge

I tried your new version here with Ableton Live 4.1.1 and the CPU usage is still running away.

Cheers

Mathman

ik_ik_ik · 18 May 2005

Hi Jorge,

Another friendly little bump 🙂

I've lost track of the recent updates and I'm sure I'm not alone. It's amazing stuff - as are some of the examples and projects that are appearing. I wish there were more hours in the day!

Slightly different to this thread but I noticed a MIDI Mono component appeared on the 0.9.3n additions which prompted me to see where things were with note allocation and polyphony issue - a.k.a. runway CPU.

Cheers,

Inigo

jorge · 18 May 2005

ik_ik_ik wrote: Hi Jorge,

Another friendly little bump 🙂

I've lost track of the recent updates and I'm sure I'm not alone. It's amazing stuff - as are some of the examples and projects that are appearing. I wish there were more hours in the day!

Slightly different to this thread but I noticed a MIDI Mono component appeared on the 0.9.3n additions which prompted me to see where things were with note allocation and polyphony issue - a.k.a. runway CPU.

Cheers,

Inigo

Hi ik_ik_ik,

Thanks for the bump, there's just so many little things to do and we're kind of trying to give priority to what's requested here in the forum.

The MidiMono component is not a proper note allocation one yet, it's basically a MidiToFloat component so you can build a constantly running mono schematic controlled by the frequency of the notes you play. We still need to implement a MidiToPoly with note management.

ik_ik_ik · 18 May 2005

Thanks Jorge! I hereby request MIDIToPoly with Note Management 😉 ...although other little things are fine too 🙂

jorge · 18 May 2005

ik_ik_ik wrote: Thanks Jorge! I hereby request MIDIToPoly with Note Management 😉

It would help a lot if someone could expand on the types of note management required. Designing it is probably more work than actually implementing it.

ik_ik_ik · 18 May 2005

I'll give it some thought. I'm sure others can jump in here too; there must be all sorts of portamento, legato, note-stealing, note-grouping and many other dimensions to consider. It'd be great to get something really well designed and flexible up front.

lalo · 19 May 2005

First ideas on note management that comes to mind :

1. Legato mono mode with LAST note priority (HI and LOW priority needed??)

2. A way to avoid the classic situation of glitches when you have notes with long release time overlapping to new notes being played; the click is due to the instant amplitude change i think.

3. A way to 'tag' the notes being played, a kind of ID given to the note played when in polyphonic mode.

4. A module to limit the polyphony.

just some idea

lalo

ik_ik_ik · 19 May 2005

Great, the ball is rolling 🙂 I think it makes sense to open a new thread in the Ideas & Request forum for the "MIDI2Poly with Note Management". Lalo I'll copy you're ideas there too to get us started.

lalo · 19 May 2005

ik_ik_ik wrote: Great, the ball is rolling 🙂 I think it makes sense to open a new thread in the Ideas & Request forum for the "MIDI2Poly with Note Management". Lalo I'll copy you're ideas there too to get us started.

great Sir 🙂

go ahead ..let's the ball roll...jorge is in 'state of grace' these days 😉

lalo

malc · 5 Jun 2005

Hi guys,

Sorry this took so long but I think we have the cpu overrun cracked now! It certainly fixes the problem Inigo posted back in April (April - wow, it did take us a while, slightly embarrassing 🙂).

If anyone wants to know the gory details I can let you know. Please give the latest release a try and let me know how you get on.

[old link]

ik_ik_ik · 5 Jun 2005

Hi Malc,

That's great news! I wouldn't be embarrased considering all the other amazing things that have been appearing from the SM camp - and believe me time is flying here too anyway 🙂 That reminds me, I should revitalise the "MIDI2Poly with Note Management" too - it started to be a promising discussion.

Really great to see MIDI Out has appeared too - looking forward to experimenting with this one 🙂

Thanks guys!

Cheers,

Inigo

Shifrin · 5 Jun 2005

malc wrote: Sorry this took so long but I think we have the cpu overrun cracked now! It certainly fixes the problem Inigo posted back in April (April - wow, it did take us a while, slightly embarrassing 🙂).

That's awesome, and midi out too, sweet 😉

Shif.

sambean · 27 Jun 2005

!Bump!

I'm getting similar runaway CPU problems with a VCO..

I have a synth module with a VCO that can have it's pitch controlled with either an ADSR or a knob value. With the ADSR there are no problems, however with the knob controlling the pitch after a minute of so of playing the sound starts braking up and everything slows right down (in synthmaker).

Sounds like a similar problem to the one mentioned, but it doesnt matter what notes are played, it happens regardless..

I can't post an example, but I'll send the file..

Sam

malc · 27 Jun 2005

Ok, thanks Sam. Send the file through and we'll take a look.

malc · 28 Jun 2005

Got your file thanks Sam.

I've been looking into this. It's a bug not a problem with your schematic. We'll get this sorted.

Thanks.