From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Tzarls ·
I´ve been thinking of this lately (and I´ve also seen this mentioned somewhere else in this forum) that if a primitive existed which did something like the "bool to true" primitives do, but instead of having a green bool input it had a stream bool input, then many of the present limitations of the event system could be solved without having to wait for a new event system. It would also give us the benefit of sample acurate triggers, for sequencers and that kind of applications.
So, what do you say devs, just one little primitive? 🙂
Sasu Honka ·
+1 here!
I have a couple of projects hanging because of the lack of sample accurate trigger for the green data.
This could be the key to have them finished!
Innovative thinking Tzarls -as usual...
Tzarls ·
Thank you, man!
Now...I wonder if the devs even read this section....mmmmmm....
oddson ·
Tzarls wrote: ...I´ve also seen this mentioned somewhere else in this forum...
One day before...
[old link]
oddson wrote: If OutSim would make some kind of stream to trigger primitive this rough approach wouldn't be needed here and in a lot of similar cases (MIDI sequencing for example)...
But it's not as simple as is may sound as it the current event mechanism structure doesn't seem to lend itself to integration with the stream data system. Others have suggested a Tick1000 mechanism but this would likely cause excessive processing in the green realm.
Perhaps something in the 1MHz range that polls a stream state is possible -- but it will not result in sample-rate accuracy.
Tzarls ·
Yep, that´s the link - the only difference being the stream in vs. a stream bool in. Either way it should give us good results, if it ever gets implemented.
I don´t think this is too complicated, since we already have a primitive that can read streams and send them as green data when triggered, so a bridge already exists.
So there´s 3 of us interested.....anyone else?
tektoog ·
Sure I am !!!!!
MichaelBenjamin ·
you mean a polystream to 4 triggers like the m2f module?
Tzarls ·
I was thinking of something more like the "bool to true" primitive, but instead of having a green bool input, it would have a stream bool input, and a green trigger output. Additionaly there could be one with a mono bool input.
MichaelBenjamin ·
ah so the trigger would then be sent exactly when the bool changes, ideally. dont know if this is possible, but i doubt it. the fastest resolution seems already too far stretched with tick 100. so how would you tell the green system that it has to create a trigger exactly at sample number 32444, when the windows timer is so loose on timing? you would need to rip out that windows timer completely and exchange it with a stable timer to make the green act reliable on timing.
Tzarls ·
Well, from SM´s point of view, as everything is realtime, it wouldn´t have to say "send trigger at sample xyz" - it would be more like "send trigger now". Of course I don´t know if the triggering system has anything to do with windows timers - AFAIK, just primitives with timers use windows timers.
Of course, if you tried to send a trigger every sample, it could crash the system. But doing something wrong in ASM would have the same effect, so...
MichaelBenjamin ·
afaik the reason why the green system processes "when it wants" is because it processes on triggers which get sent whenever a tick or a change is received, and these triggers/ticks are based on that inaccurate windows timer, so you just can not foresay the time when the call for a recalculation gets executed. a streambool to trigger probably would have the same timing issues than a m2f with a tick 100. but if i am wrong and there is some trick to get the green code executed on a stable time base, im all for it.
for now, the best time accurate method to execute once on demand at a certain time would be with in asm with the jz and a 0-1 pulse.
exonerate ·
MichaelBenjamin wrote: afaik the reason why the green system processes "when it wants" is because it processes on triggers which get sent whenever a tick or a change is received, and these triggers/ticks are based on that inaccurate windows timer, so you just can not foresay the time when the call for a recalculation gets executed. a streambool to trigger probably would have the same timing issues than a m2f with a tick 100. but if i am wrong and there is some trick to get the green code executed on a stable time base, im all for it.
for now, the best time accurate method to execute once on demand at a certain time would be with in asm with the jz and a 0-1 pulse.
No triggers are not based on windows timers, sending a trigger NOW doesn't require a timer where as sending one in the future does.
The main problem with triggers and green data in general, is that it is on a lower priority thread to the audio, which means that if there's a lot of audio processing going on and the CPU is very busy some triggers may not be processed at all, or just arrive late. Then add to that the inaccuracy of windows timers and you can pretty much in the current event system never know, or say, exactly when a trigger will be sent.
So even if a sample accurate trigger was able to be sent in SM, it may not stay very accurate as it flows through the schematic due to the fact it's on a low priority thread.
Of course though I would welcome and actually want such a thing because it would cut out the inaccurate windows timer,
though I don't think it would be possible.
Basically the audio section in SM has no function calls where as I'm pretty sure that the green domain is nothing but.
For a stream to trigger primitive to work it would need to do something like this I guess...
//Warning pseudo code!!
float F1 =1;
float sendTrigger;
movaps xmm0,bool;
cmmps xmm0,F1,0; //Check if bool == 1
movaps sendTrigger,xmm0;
if (sendTrigger == 1)
Trigger(); //supposed to be a function call.
Which wouldn't be possible as all the audio code is compiled to SSE asm so in the mist of that it would have to do something like I have shown (basically call the function which creates a trigger).
So I think it's just not possible.
The much anticipated event system will work by tagging all events with a time stamp and these event will be processed at the same priority as the audio, basically synced to it.
Lately the focus of development has been purely bug fixes, so I'm hoping the plan is to get this version of SM as stable and usable as possible and then they can switch all resources to working on version 2 and the new events system.
Cheers 😉
Exo
Disco_Steve ·
excellent post exo,thankyou.
Tzarls ·
In the end, what we really need is an official statement from the devs.
And by the way, how do I get SM-X?
Nu Audio Science ·
Its in the SMX forum
If you cant see that ask Malc to allow you to see it
I wouldnt bother though its way out of date and not very useful to be honest
In all honesty at this point that forum should really be removed because i think it raised expectations of a few me included
NAS
Tzarls ·
Well, I´m just curious about it. I´ll ask to allow me into that forum. Thanks NAS.
Tzarls ·
THis is a cheap excuse to bump this post. 😉
Now we know that we can achieve triggers faster than with the tick100.
Own Voice Recording
So please, I really think this primitive is a must.
Tzarls ·
Malc, any chance on having this primitive? Or at least knowing wether it can be done?
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker