[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-users] BooleanUGens (was Re: conditional statement in SynthDef)



I first tried to add ==, but a recompile of the library threw all sorts of errors. It seemed to me that, at least on a first look , adding == as a UGen would break code. I really didn't spend much time trying different approaches. It seemed like it would be very simple to code in C, so IsEqual made sense to me.

If there are other solutions that is fine, but nothing was coming up on the list after Dan mentioned that there wasn't a way for == to return 0 or 1 for an if statement inside a SynthDef. It took 10 lines of C code and seemed like it would make sense. Very little work.

If there is another way to do it, by all means, please do. This is why I included it in my lib... I'm not a developer, it seemed to me not to break anyone else's code, and did what it needed to do. Since nobody else had ever felt a need for it, I didn't see any reason to try and have it put into the main lib since, in general, I think that should still remain pretty lean.

If for some reason any of the other solutions don't work, and if anyone thinks this would be a good addition to the standard lib, I would gladly send the C code to a developer to use however they wanted. Really doesn't matter to me.

Josh

******************************************
Joshua D. Parmenter
http://homepage.mac.com/joshpar/

"...Some people think a composer's supposed to please them, but in a way a composer is a chronicler... He's supposed to report on what he's seen and lived." -Charles Mingus

On Sep 5, 2005, at 9:19 AM, Scott Wilson wrote:


On 5 Sep 2005, at 16:53, James Harkins wrote:


On Sep 4, 2005, at 4:50 PM, Joshua Parmenter wrote:

So the issue is merely that AbstractFunction doesn't implement == and != -- why could UGen not simply implement those two operators?


This is sort of what I meant when I said use the same syntax. Sorry, should have been clearer. But given that BinaryOpUGen already supports this is there a reason why this shouldn't simply be done in AbstractFunction? As I noted before it inherits Object's methods wherein equality equals identity, so there'd be no lost functionality. Don't know if this would break anything, but seems like it might be useful with Function composition anyway.

S.

_______________________________________________
sc-users mailing list
sc-users@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-users