From the original SynthMaker forum (2004–2014), with its members’ names and dates.
DigitalWhiteByte ·
I can't understand that define a issue or I missed anything about this primitive. In the schematic annex there are differenzizzioni about trig get, and the result is that it seems that I need two or more trig to return a correct value. I don't know then if it fails or is this his work.
oddson ·
It's a bit dodgy on the face of it but I think much of it has to do with the devs assuming you'd never connect a float directly to a M2F (I mean, what would the point of that be?).
Examples 1 and 2 seem to be the same thing: the trigger is getting the last value of the float. When it's a stream you'd normally want the value as close to the time of the trigger as possible, so it doesn't wait for the value to update. In example 2 to the float input is clearly reading the trigger at the stream input; there normally wouldn't be a trigger at this input so it's not much of a bug.
Example 3 may be showing that there is a lag with the random generator. Sometimes the new value is ready before for the trigger from the trig/divide (which is the second output) arrives and sometimes it is not. Again, the devs would have assumed whatever value is present in the stream should be output without delay... in a green component they would need to wait until the thread had propagated... but here they may have assumed whatever is present in the stream is what the user is looking for.
The 'working' example works because it's updating 49 times before the value changes.
Here's a better way to read the float without sampling it 49 extra times:
DigitalWhiteByte ·
In fact did not own way connect a green to a M2F, but the case wanted this. 😊 I was trying to use it as trig block, in that it returns a trig only if the value changes. Anyway it was a pure case linking and I had noticed this thing.
Always thanks
oddson ·
DigitalWhiteByte wrote: ...I was trying to use it as trig block, in that it returns a trig only if the value changes. ...
Not at my SynthMaker machine but this old image shows how to limit triggers to value changes... it's an integer value here but works with floats too and if you just want the trigger take it off the trigger switch output
DigitalWhiteByte ·
Use already this way, but I wonder which of the two ways, used in the schematic, requires less computation for the CPU?
trogluddite ·
My best guess would be that keeping it in green would be better. If I run your schematic, and then delete the M2F, there is consistently a drop of 0.1% on the CPU (this is on an intel atom, so it's a tiny difference!) I would take that to mean that there are at least a few cycle of CPU being constantly used at sample rate by the M2F. That would make sense - there are no triggers in streams, and there could be multiple sources and switching/selecting upstream, so the stream input would have to be buffered into a memory location at sample rate at the very least, I would think.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker