From the original SynthMaker forum (2004–2014), with its members’ names and dates.
Tzarls ·
Well, this isn´t the first time I ask for this but I´ll do it again since, at least right now, there is no evidence of a new timing system on the way.
I´d like a "bool2true" and "bool2false" primitives. Such primitives should accept stream bools, and send triggers just like the green versions. Only difference is that the triggers fired by this primitive would have a great possibility of being sample accurate.
Now, a few additional ideas.
A "samples between ticks" input (int). This could be used to prevents firing too many ticks at once. The ticks not being fired should be placed in a buffer and sent, on by one, after the desired samples value has elapsed.
A "clear buffer" input (trigger). This could be used to erase any ticks in the internal buffer.
A "triggers in buffer" output (int). This could be used to check if there are ticks in the buffer. Could be of some use to have such information.
Finally, there should be "white" and "blue" versions on such primitives.
Please, take some time to develop this primitives. That way you could have my £20! 😉
infuzion ·
We all would like perfect stream to green primitives, but is imposable with the current architecture.
Tzarls ·
Malc once wrote that triggers are "born" in the stream realm, and because of that a primitive like the one I´m describing could be built. I don´t see why it couldn´t be done in the current architecture.
Redraw Limiter not quite working
@Tzarls:
That is possible yes. In fact that's pretty much how the events system works. So yes you could go as far as generating the event but then convert it to a trigger for use with the current system instead of introducing a new system where the events flow from component to component. This way you would get the timing aspect of the new system at least.
As infuzion points out you'd have to be careful not to do too much processing or cpu will be compromised. Might be better for us to pass the trigger across threads so that the audio thread can continue while the trigger flurry processes.
This was written more than a year ago. I´m pretty sure this is worth developing, or at least giving it a shot!
trogluddite ·
Tzarls wrote: As infuzion points out you'd have to be careful not to do too much processing or cpu will be compromised
I think this is the nub of the problem. The green trigger system's "run on demand" way of processing is a brilliant way to save CPU on GUI's etc. - but it entails a lot of CPU overhead for tracking the trigger flow and there are many green primitives which have poor efficiency (FFT anyone?).
So you need absolute certainty that you can't generate triggers faster than they can be processed. I wonder if OutSim's reluctance to release stream->green comes from this; in the hands of less experienced users they could easily generate a reputation that "SM is crap because it uses too much CPU" - imagine 500 ticks per second triggering a Redraw or FFT, a recipe for instant audio crackles and pops as the CPU tries to keep up.
I would suggest at least that such primitives should be R&D "use at your own risk" components - something to be used only by experienced SM'ers who have a good understanding of the CPU load problems that may be caused.
Personally, I'd be happy with a blue stream MIDI event primitive - that's where the timing really matters - you could then program sequencers etc. using code/ASM. If there were a 'hopped' module container, you could even use stream primitives for creating sample accurate algorithms that were low CPU.
oddson ·
trogluddite wrote: ...I wonder if OutSim's reluctance to release stream->green comes from this; in the hands of less experienced users they could easily generate a reputation that "SM is crap because it uses too much CPU" ...
Better to have everyone say SM's crap because you can't do much with it?
(A poor designer can already overload the CPU.)
If there were a stream2trigger primitive, even with a few milliseconds of lag (ASIO buffer size?), you could at least trigger midi events at something like musically relevant timing accuracies.
The problem is OutSim has moved on... I have too. 🙁
Tzarls ·
I too think that how dangerous a primitive can be shouldn´t be a reason for not releasing it. And from how I suppose things work internally, there shouldn´t be a lag at all - at least not larger than the inherent latency introduced by the size of the block passed by the host to any VST plugin.
trogluddite ·
I wasn't suggesting that it shouldn't be tried, or that OutSim are right to dismiss it out of hand - merely that if it hasn't been included yet, then there must be a reason. OutSim must have decided that such a feature is either commercially not viable (too few customers vs. too much development effort), or there is a sound technical reason why it won't work reliably.
SM2 broke a lot of people's schematics due to the change in code stages, and we have had weird problems before when the trigger system has been tweaked in updates - it's not surprising if OutSim don't want to risk breaking the parts that are already reliable in order to satisfy a handul of eggheads who are trying to push SM beyond its design limitations.
We all have our own personal favourite features that we'd like to see so that we can remain in our comfortable SM sandbox - but, ultimately, if SM doesn't provide the tools you need, then you have to look elsewhere. Personally, I see it as a great tool for hobbyists - but if I were developing commercially to a specific design brief, I would be learning C++/VST SDK.
Tzarls ·
Well, this primitive shouldn´t change anything about the present trigger system. It´s just a primitive built around the existing event system. Now, I´ve already taken the road of C++/VST SDK, but still find SM useful for certain tasks. And I have some old projects that I need to keep in SM, basisically because my C++-fu isn´t that good yet. 😉 Plus, I really believe this primitive could give SM a much needed functionality at a very low cost.
attic ·
Personally, I'd be happy with a blue stream MIDI event primitive - that's where the timing really matters - you could then program sequencers etc. using code/ASM. If there were a 'hopped' module container, you could even use stream primitives for creating sample accurate algorithms that were low CPU.
+1
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker