From the original SynthMaker forum (2004–2014), with its members’ names and dates.
mwvdlee ·
Not sure if this is a bug or a feature request, but there are no monoboolin and monoboolout datatypes in the Code and Assembler modules. If you hook up streamboolin/-out to blue, the connection type is obviously supported, but the keywords are not.
It's only a minor issue, since I just use the stream* datatypes always, but it seems like an omission nonetheless.
exonerate ·
Well I think the only reason polyin and monoin are still there is for backward compatibility, no one actually uses them.
So I see no reason to add monoboolin.
Cheers 😉
Exo
mwvdlee ·
exonerate wrote: Well I think the only reason polyin and monoin are still there is for backward compatibility, no one actually uses them.
So I see no reason to add monoboolin.
Cheers 😉
Exo
Only reason I can think of is when a certain component is explicitely meant for either poly or mono. I can imagine a component only being useful when it's used either in poly or mono. At the very least it's convenient for marking the in- and outputs in the required color 🙂
But as I said; it's a very minor issue. Would be nice to include it if it took Malc about 10 minutes to do, otherwise just forget I ever asked 😉
trogluddite ·
exonerate wrote: Well I think the only reason polyin and monoin are still there is for backward compatibility, no one actually uses them
They can be useful occasionally - for example, I have hopped versions of the pack and unpack that use them; they have saved me a fair old bit of CPU on occasions, especially where all four sse channels aren't needed. The bool*s I can happily live without though - conversions between float/integer/bitmask take up CPU wherever they are, and IMHO it's best done explicitly inside the code block where the coder has full control.
mwvdlee ·
trogluddite wrote: exonerate wrote: Well I think the only reason polyin and monoin are still there is for backward compatibility, no one actually uses them
They can be useful occasionally - for example, I have hopped versions of the pack and unpack that use them; they have saved me a fair old bit of CPU on occasions, especially where all four sse channels aren't needed. The bool*s I can happily live without though - conversions between float/integer/bitmask take up CPU wherever they are, and IMHO it's best done explicitly inside the code block where the coder has full control.
Can you safely pass an SSE bool (0x00000000 or 0xFFFFFFFF) as a float anyway?
I don't quite understand what you mean by "conversions between float/integer/bitmask take up CPU". Do you mean there is some implicit cost to using boolean datatype or do you mean when you manually convert between the types in code?
addition: Apparently you CAN'T pass SSE bools as floats between modules. I'd post the schematic to show, but this subforum does not allow attachments.
trogluddite ·
mwvdlee wrote: Do you mean there is some implicit cost to using boolean datatype or do you mean when you manually convert between the types in code?
Sorry, didnt explain myself too well there.
At the moment all values going into and out of code/asm primitives are treated as floats. The streambools have a different symbol, but they do exactly the same as a normal streamin streamout as far as I can tell.
I think that this makes the streambools potentially confusing because if you input a green bool into a streamboolin you just get zero or one, rather than a logical bitmask value - using the normal streamin makes it clear that you still need to do a comparison on the green input if you want to do logic with it. And you can't convert a bitmask to a green bool either, a mono to float just gives a NAN.
The alternative would be little bits of hidden code in the primitives to make streambools work as proper boolean bitmask inputs with green data. Or just ditch the streambools to avoid any confusion. (quite possibly I'm the only one daft enough to have got confused by it - happens a lot!)
mwvdlee ·
trogluddite wrote: mwvdlee wrote: Do you mean there is some implicit cost to using boolean datatype or do you mean when you manually convert between the types in code?
Sorry, didnt explain myself too well there.
At the moment all values going into and out of code/asm primitives are treated as floats. The streambools have a different symbol, but they do exactly the same as a normal streamin streamout as far as I can tell.
I think that this makes the streambools potentially confusing because if you input a green bool into a streamboolin you just get zero or one, rather than a logical bitmask value - using the normal streamin makes it clear that you still need to do a comparison on the green input if you want to do logic with it. And you can't convert a bitmask to a green bool either, a mono to float just gives a NAN.
The alternative would be little bits of hidden code in the primitives to make streambools work as proper boolean bitmask inputs with green data. Or just ditch the streambools to avoid any confusion. (quite possibly I'm the only one daft enough to have got confused by it - happens a lot!)
I guess the confusion sets in when you try to make things usable for generic situations. Upto now I've done very little code that is not purpose-build for whatever situation I'm in. Thing is that output a boolean directly to a float doesn't seem to work; output the 0xFFFFFFFF boolean TRUE through a float, input it into another Code module and it is no longer 0xFFFFFFFF. (Please doublecheck to ensure I didn't mess up my tests on this). This means that if you want to output a logical true/false value through float, you actually would need to do conversion as well, or it won't get input correctly in the next module. As far as I can see, the only confusion is when converting bools from/to green. While you're staying in mono or poly there are no problems with bools. Sounds to me the green bool to stream bool conversion isn't quite as it should be. Ah well, too late to fix that now.
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker