
On 9/19/07, Scott Wheeler
I'll share my thoughts on livecoding practice and so on too, later. I just wanted to say now that bug reports benefit from a bit more exposure then this paragraph got in your mail, hence this rather explicitly topic-changing reply. I don't see why that would affect matters either, this is in reference to the "set" command that also broadcasts a event, right? The one thing I could think of would be a name space issue. Normally sporked shreds have their parent's namespace but this wouldn't be the first time things went a little odd when inside of classes and you certainly have no shortage of those here. Also; if it's namespace that should yield a complaint. Strange. :¬) Cheers, Kas. // MIDI Event IDs

Kassen wrote:
[...] I don't see why that would affect matters either, this is in reference to the "set" command that also broadcasts a event, right? [...]
It does so in one of the subclasses (the generic one for event broadcasting). Just explaining a little of the logic there: Every time a control is instantiated it registers itself with the ControlDispatcher, which itself is a specialization of the MIDI handler. The base implementation doesn't do anything interesting when the control is modified, but in event subclass it broadcasts an event. Since all overloads are implicitly polymorphic in ChucK, this Does The Right Thing. In the FooControl it does whatever action is specified in the overloaded version. (This explanation assumes familiarity with OO basics -- if any of it isn't clear I can give more details.)
[...] this wouldn't be the first time things went a little odd when inside of classes and you certainly have no shortage of those here.
Aside from being generally an OOP fan, it certainly makes a lot of the things in there a lot easier. Cheers, -Scott

On 9/20/07, Scott Wheeler
I wasn't criticising you; I could tell you are a OOP fan and that's cool. I also know (because I too use classes if not always with as much enthusiasm as you do) that with ChucK some things that normally work fine act weird when done inside of classes, just this summer we had some especially obnoxious cases of that. So; I was trying to help pinpoint the source of the issue because as far as I could see after a quick look what you are trying should work just fine. Yours, Kas.

While I haven't thoroughly gone through the code Scott posted, one thing did catch my eye: if(node.item.cc == control) { node.item.set(value); } node.next @=> node; This looks like a nice corner case that, if spork was used, the spork- handling code might not anticipate. Investigating further I was able to come up with a minimal example that crashes chuck 1.2.1.0b on OS X intel: class Someclass { int i; fun void f() { 0 => i; } } new Someclass @=> Someclass @ someclass; spork ~ someclass.f(); // placing me.yield() here prevents the crash new Someclass @=> someclass; me.yield(); // necessary to let the sporked shred execute and cause crash While Scott's code doesn't seem to be causing any crashes, the spottiness of using spork as he described and the crashing caused by the above code seems to indicate that something is not quite right with the spork member function implementation. Scott, maybe sticking a me.yield() after spork ~ node.item.set (value); would make things work a little better. Although, unless you are trying specifically to control shred execution order, I don't actually see the utility of spork in this particular case, as the set () function doesn't allow time to pass. spencer On Sep 20, 2007, at 3:16 AM, Kassen wrote:

Spencer Salazar wrote:
Scott, maybe sticking a me.yield() after spork ~ node.item.set (value); would make things work a little better.
Yes, that does make it work.
Well, it doesn't advance time in the base class, but it does in non-toy specializations. In real usage, I mostly use that class to map buttons to fade in/outs or to modulate parameters. (Or another interesting one -- a control smoother, which doesn't allow the control to change more than a certain threshhold over a certain time and then catches up to the end value.) With the current code I wasn't able to control more than one (time-advancing) thing at a time. -Scott
participants (3)
-
Kassen
-
Scott Wheeler
-
Spencer Salazar