[chuck-users] sporking member function and static
Atte André Jensen
atte.jensen at gmail.com
Tue Jun 20 15:11:21 EDT 2006
Spencer Salazar wrote:
> Essentially, within a
> static function, you cant access non-static member variables or
> functions unless they are associated with an explicit instance of the
> class--ie you need InstanceName.start() or InstanceName.data, not
> just start() or data.
Thanks alot! That was exactly the kind of answer I was hoping to get. It
all makes much more sense now. In retrospect, I think I should have seen
it my self, sbut then again...
> This is one of the more subtle points about static member functions;
> it would probably help to mention this in the docs, and also I think
> it should be a compile error.
It should very much be in the doc. Subtle sometimes means "you never
figure out yourself why this special case doesn't work"...
> But yes, even with that issue resolved, your code wouldnt work
> because of the sporking member functions issue. Since static member
> functions seem to work with spork, have you considered making all of
> the members of Time static?
I had even tried, but must have missed something. In the mean time I
made it work by moving most functions outside the class (for proof of
concept + maximum clutter), but after reading this I managed to
rearrange everything back in the class.
> Although thats probably undesirable in
> the long run (you couldnt run multiple different tempos within the
> same chuck virtual machine), it should operate well enough if you
> only need a single master tempo.
I wouldn't say more tempos wouldn't have any use, but I find it hard to see.
Basically what I have is four sporked functions each sending out
messages of my own Event subclass "timeEvent" (should be named more
approppriate) that are defined like this:
static timeEvent measure;
static timeEvent quarter;
static timeEvent eight;
static timeEvent sixteen;
Each message is tagged with whics measure in the period, which
quarternote in the measure, which eightnote in the quarter note and
which sixteennote in the eightnote they are. Printing out this gives
(snipped, with sixteennote triplets):
0 : 0 : 0 : 0
0 : 0 : 0 : 1
0 : 0 : 0 : 2
0 : 0 : 1 : 0
0 : 0 : 1 : 1
0 : 0 : 1 : 2
0 : 1 : 0 : 0
0 : 1 : 0 : 1
0 : 1 : 0 : 2
0 : 1 : 1 : 0
0 : 1 : 1 : 1
0 : 1 : 1 : 2
0 : 2 : 0 : 0
0 : 2 : 0 : 1
0 : 2 : 0 : 2
0 : 2 : 1 : 0
0 : 2 : 1 : 1
0 : 2 : 1 : 2
0 : 3 : 0 : 0
0 : 3 : 0 : 1
This is printed from a listener, listening for the sixteen note stream.
This all means:
1) When you sit somewhere you can easily place something on say 4 in
every other measure, simply listen to the quarternote-stream and react
when you woke up by the last quarter in an even/uneven bar. If you
really listen for the last beat and not the beat tagged 4 the listener
would even execute meaningfully and 100% synced in 3/4.
2) I have set up a basic midi-keyboard-remote-control. Tapping on the
lowest C five times (1-2-3-4-1) will set the tempo to what was tapped +
restart the senders on the final 1. This way I hope to be able to
syncronice to live drummers and be able to adjust to them, should they
loose sync with chuck. Also simply tapping on the lowest C# will restart
the senders without changing the tempo. I tested it (with Janet
Jackson's "Rhythm Nation" :-)) and it's possible, and the CD is
listening even less than (most) drummers...
> Would that work until the current
> sporking behavior is cleaned up?
I think it would work regardless. This setup doesn't really make sense
if two or more senders are spitting out say quarter-note events at
peace, love & harmony
http://www.atte.dk | quartet: http://www.anagrammer.dk
http://www.atte.dk/gps | compositions: http://www.atte.dk/compositions
More information about the chuck-users