From the original SynthMaker forum (2004–2014), with its members’ names and dates.
jobro ·
We have a white and green boolean signals. Lots of green boolean primitives, not so many white primitives. It would really help if we had converters between those.
Say you want to add a bit of fluttering in the frequencies á la analog synths. You have green random primitive, but you have no way to trigger a new value with white booleans.
oddson ·
Which will show true iff any of the poly streams are true...
And the other way is trivial
What am I missing? 😕
trogluddite ·
oddson wrote: What am I missing?
Sadly, "the other way" is not so simple as just connecting green to stream. Green booleans use... False = 0, True = 1. Stream booleans are more tricky, as they are bitmasks. False = 0, True = (binary) 11111111111111111111111111111111 (all 32 bits set true). As an integer, that value would be a pretty big negative numbers (EDIT: wrong, it is -1, see Cyto's correction below), BUT stream values always use float notation - and that arrangement of bits does not come out as a valid float value - it is literally "Not a Number" (NaN). This is why you need the "& 1" in the stream to green example. To convert the other way, you have to do an explicit conversion to a bitmask. The simplest way is to use a not-equal comparison with zero...
streamin GreenBool; streamboolout StreamBool; StreamBool = (GreenBool != 0);
...or in ASM...
streamin GreenBool; streamboolout StreamBool;
pslld xmm0,32; //Quick way to make zero without needing a variable cmpps xmm0,GreenBool,4; // Not equal comparison movaps StreamBool,xmm0;
Note that both of these code snippets will work equally well for mono, mono4 and poly streams
oddson ·
trogluddite wrote: Sadly, "the other way" is not so simple as just connecting green to stream.
Ok... 😕 Then what's happening when I connect this and toggle the green boolean?
trogluddite ·
oddson wrote: Then what's happening when I connect this and toggle the green boolean?
Aha, this is just about the only exception to the general "all bits" rule... The 'True' green boolean input value is (in stream terms) a float one. This is then being 'Anded' with float one inside the little bit of code - so the output is also one, as the two bit patterns will be identical. However, this will not work in the general case. For example if your boolean was used in a typical code statement like this...
x = x + (Boolean) & y;
...unless y just happens to be one, the bit patterns will no longer match up, and the '&' will behave very unpredictably. You can show this by going inside the little code box and changing the '& 1' (and the green 'equals') to some other number - the readout will stop working. In effect, the streambool readout is not truly robust, as it is not really checking that the bitmask is complete for all 32 bits - so it is not a reliable indication that the mask would work when used inside any old piece of code.
To be sure that a bitwise '&' will work to 'reveal' any arbitrary value, the bitmask must be made with all bits set to one (or zero if false) using the zero comparison I showed before
philter5 ·
hey trog i think this maybe the solution for a problem i had. i have a schematic where in NEED to convert the polyboolean trigger/gate output from the midi2poly module to blue stream (or maybe green data? 😕 ) and then back to polyboolean trigger/gate. is that even possible? i have a workaround but a solution would be a lot better 🙂
trogluddite ·
NOTE: Topic moved to 'Examples' - its original location 'Ideas and Requests' does not allow attachments (except for very special people like Mr. Oddson!)
philter5 wrote: polyboolean trigger/gate output from the midi2poly
Hmm, so if I understand right, you need to take the polybool gate/trigger (separate for each note), and end up with a polybool that will work for all notes simultaneously? Here's a schematic with just that - you'll notice that playing any new note re-triggers the Decay envelope for all notes that are currently held down...
...notice anything strange? Yup, my little modules for converting streambool to regular (float) stream (and vice versa) aren't even connected!! Just out of curiosity, I forced the connection between the two different data types, and it still works! Maybe, a quirk of the envelope, or maybe it always works (for triggers), not sure yet. If I'm right, you would still need the conversion codes if going to green or for the gate - I think it only works because a trigger will only happen for one sample, and only on one 'channel' at a time (i.e. when the poly's are added together, the result stays the same) (NB - to force a connection between the 'wrong' data types, hold CTRL+SHIFT when making the links).
philter5 ·
trogluddite wrote: ...notice anything strange? Yup, my little modules for converting streambool to regular (float) stream (and vice versa) aren't even connected!! Just out of curiosity, I forced the connection between the two different data types, and it still works! Maybe, a quirk of the envelope, or maybe it always works (for triggers), not sure yet.
hehe good to know i noticed exactly this behaviour in some of my messy experimental schematics (first thought: WOW, strong good old acid coming back again 🙂 >KIDS DON`T DO DRUGS ! ....but i pinned that "mindtrick" to the too little sleep i had 😉 )
cyto ·
trogluddite wrote: False = 0, True = (binary) 11111111111111111111111111111111 (all 32 bits set true). As an integer, that value would be a pretty big negative number...
I don't mean to be nit-picky here, but that is not quite true. The integer representation of all-bits-on is simply -1. For the longest time I, too, thought that the first bit in the integer was simply a "sign bit" like it is in float-32. And I always cursed when SM wouldn't let me put -2147483647 in an assembly block, to declare a "true" value. It wasn't until I built that little IEEE754 converter (posted somewhere around here under "cytoTools") that I realized that was wrong. Anyway, I don't mean to muck up the water here, but I thought it was pertinent to the topic at hand to point this out... if you want a "true" value in assembly, declare an int with a value of -1.
-cyto
infuzion ·
cyto wrote: if you want a "true" value in assembly, declare an int with a value of -1.
All this ASM voodoo!
trogluddite ·
cyto wrote: I don't mean to be nit-picky here, but that is not quite true.
No need to apologise, I really should have spotted the two complement - daft thing is, I'm sure I've used that principle in SM before we had the integer NOT/XOR primitives - doh! Takes me back to my 8-bit Z80 ASM days - the Joy of Hex! 😉
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker