SynthMakerMichaelBenjamin ·
stage 0 only gets executed when there is a free channel available, not when a voice gets stolen. original topic: how to init a mem array on voice retriggering?
stage 0 does not retrigger on stolen voice
From the original SynthMaker forum (2004–2014), with its members’ names and dates.
MichaelBenjamin ·
bump - would be nice if this could be fixed
MegaHurtz ·
Stage 0 only gets calculated once on "recompile". As far as i know it cant do ramps for that reason. So inherently it`s getting a recompile on note off.
MichaelBenjamin ·
what do you mean? stage 0 gets executed once for each new voice, but only if theres a free polychannel left - so it does not get triggered if a new voice replaces an old at the same channel. i think the stage 0 triggering should be consistent on every voice spawn no matter if stolen or not.
MegaHurtz ·
The cpu drop indicates there is a stop compiling at note off. When you press the note again it starts initializing the code again. This would mean the contents of stage 0 have to be recalculated. Wich saves cpu in some cases to get a variable wich is static.
MichaelBenjamin ·
ok, but i dont understand - how is this related to the behaviour mentioned at the topic?
MegaHurtz ·
The rising tone is becouse the actual ramp is executed outside stage 0. The other posts are barely related to stages. To elaborate.. If you would do a recompile during stolen voices You would have a problem to maintain sound and actual stealing of the voice. So it`s kind of inherent to not wanting any difference in behavour at that point. And wanting a cpu drop when no voices are active.
MegaHurtz ·
is there a way to reinitialize a code mem array when retriggering a voice on the same channel? currently it seems like the mem keeps its data from the previous voice. stage(0) { loop(256) { mem[index]=0; index=index+1; } } does not work. any ideas?
This is a clever bit of code, and it will work. But you know that alredy. Since the midi is approx controlrate, clearaudio? Edit: Excuse the dutch way of composing a sentence, may come across as a bit blunt.
MichaelBenjamin ·
ah ok you are referring to the linked topic above, i completely forgot that - its old and was when it first occurred to me that stage 0 retriggering is not consistent.
but that code: stage(0) { loop(256) { mem[index]=0; index=index+1; } }
does NOT work on stolen voices since stage 0 does not get executed then. why do you say it will work?
MegaHurtz ·
It won`t. It only does it when the code is initialised.. since it gets de-initialised (for a performance boost) on note off. it gets re-initialised when a note is played. So im actally telling everything bad that happens when you press clear audio in the middle of a note. would happen if stage 0 gets re-initialised on stolen voices.
If through a spurr of creativity you can get the stealing to happen on a new voice. Wich was off.. then it does. But.. I was wondering since you probbably have a hard time batteling this phenomena. Why not put it inside a jz. (I think as efficient) and saves a tonn of working around.
MichaelBenjamin ·
i think you mix up the spawning of a 4poly block with individual voice spawning.
when i press a note with a maximum polyphony of 4 then stage 0 gets executed and the complete block gets spawned. 3 voices left inside that block. when i hold that note and press another one stage 0 also executes for that second voice within the same 4 poly block. 2 voices left. now i can press 2 more notes and each one gets their stage 0. now the problem arises - when i press another note and the poly block is already filled with 4 voices, a voice gets stolen - and stage 0 does not get executed for that one.
MegaHurtz ·
Aah so yr saying it happens on the fourth note only. Still has no direct implication on the mechanics. Its inherent to synthmakers efficiency solution.
MichaelBenjamin ·
MegaHurtz wrote: Still has no direct implication on the mechanics. Its inherent to synthmakers efficiency solution.
are you trying to talk me into believing it is being a good behaviour which cant and otherwise also should not be changed?
MegaHurtz ·
yes.. At least heres my 2 cents. I dont think it`s a bug. More of a byproduct. On the other hand being an educated sounddesigner im used to be proven wrong. Strangely ive gone attracted to it in an unnatural addiction to the sweet pain it`s bringing 😉 No wonder I like S|M so much. But seriously ^^ you can only rely on George or Malc to determine if it`s a bug.
PZ!.
MichaelBenjamin ·
ok so you seem to like this behaviour or have a schematic that benefits from it. in most of my cases its unwanted since its irregular, but i can imagine some cases where it could indeed be used as a kind of effect. but in any way i would prefer 100% regular behaviour for stage 0 so that you can control the wanted exceptions for yourself later on in code. like it is now we have no control over this stage retriggering depending on max poly.
maybe the best solution would be an option for stage 0 to retrigger or not if a voice is already on the same channel.
MegaHurtz ·
Im guessing it can be helped with a couple of bytes for emergency`s.
MichaelBenjamin ·
ok, because i cant make sense out of your sentence you now you have overstretched my willingness for a compromise. i take a step back and say again: its 100% a bug and just because you enjoy that bittersweet wonkyness doesnt mean that it should not be corrected.
your thing is another feature, thats like an additional trigger 0-1 bang stream output from the v2poly module everytime a voice gets stolen. so you could use that then to make your weird exceptional stolen voice effects. you would have my vote for that feature request. but dont come here in my bug report and try to convince me otherwise.
first stage 0 needs to retrigger 100% then another streamout for the stolen voice trigger can be added.
MegaHurtz ·
Hehe.. Whatever you want is fine with me. Srry man I honestly tryed to give you my point of view.. Dont be angry you crack me up here. I dont have never implemented this.. And I shure as heck dont want it to work.. EVER! Yust trying to shed another light on the sittuation 😀 +1 for the wonky retrigger on stolen voice thing. Alright? 😕
oddson ·
Malc had said this would be changed someday.
MichaelBenjamin ·
ah i was only artificially mad, not real. no worries.
thanks for the link, but thats almost 4 years old and the retriggering already has been changed with the hops being individually synced to notes not blockwise. maybe this could be the next fix to that part.
this fix is quite crucial for low poly and monosynths if you dont want to reset everything manually with the env primitive and additional code for each module.
stw ·
just want to throw in my vote for this!!
This should be one part of a enhanced voice management including a way of changing the voice steal mode which is utterly underdeveloped and simply not up to date! The top entry on my personal most urgent change wishlist.
MegaHurtz ·
I do get the feeling this would be a problem that stretches by the amount of notes you`d want to play. So if you keep one chn open it happens at 5 and so on. Wich might well be solved superficcially with a trigger. But the use of stage 0 as a low cpu zone gets slightly diluted. Especcially when you need to have extra voices active.
I still don`t get why a jnz on trigger untill end, wouldnt solve any of these problems. Without slowing down the rest of the program for everybody. The incorperation of define do end and call can be a possible fix. But with the wire scheme I suppose this would be a bloody mess to use.
Lets hope the fix for this problem is rooted in newer processor capability`s. Shure am interested in the way this would be solved.
Wrote something here? To have a post removed or your name hidden, write to [email protected].