Retrieving the 'playhead' position of PlayBuf?

[bitbutter]

Is there an elegant way to retrieve the 'playhead' position of a PlayBuf (from outside the synth's synthdef)?

Here's some test code with a commented-out line that represents the way i'm hoping to be able to query the PlayBuf object.

Code:

(
s = Server.local;
b = Buffer.read(s,"sounds/a11wlk01.wav");

SynthDef("help_PlayBuf", { arg out=0,bufnum=0;
Out.ar(out,
PlayBuf.ar(1, bufnum, BufRateScale.kr(bufnum))
)
}).send(s);

x=Synth("help_PlayBuf",[\bufnum, b.bufnum]);
)

(
SystemClock.sched(0.0,
{
// x.playhead_position.postln;
0.1;
}
)
)

Is something like this possible? (would i have to 'manually' keep track of elapsed time/frames somehow?)

[dewdrop_world]

Not with PlayBuf. But you can use a Line ugen to keep track of how long the PlayBuf has been playing.

Or, perhaps better, use a combination of BufRd and Phasor -- then the Phasor is the playhead and you always know exactly what it is.
James

[bitbutter]

Not with PlayBuf. But you can use a Line ugen to keep track of how long the PlayBuf has been playing.

Or, perhaps better, use a combination of BufRd and Phasor -- then the Phasor is the playhead and you always know exactly what it is.
James

Thanks James. With a bit more research I'd also decided that BufRd+Phasor would be a more flexible approach.

Code:

(
s = Server.local;
b = Buffer.read(s,"sounds/a11wlk01.wav");

SynthDef("help_PlayBuf", { arg out=0,bufnum;
var ph = Phasor.ar(0, BufRateScale.kr(bufnum), BufFrames.kr(bufnum));
var br = BufRd.ar(1, 0, ph);
Out.ar(out,br);
}).send(s);

)

(
x=Synth("help_PlayBuf",[\bufnum, b.bufnum]);
SystemClock.sched(0.0,
{
// x.playhead_position.postln;
0.1;
}
)
)

Now i just need to access the phasor's position from code outside of the SynthDef (the x.playhead_position.postln; line is a sketch of how i was hoping to be able to access it). Perhaps SendTrig can help...

[dewdrop_world]

Yes, SendTrig is a good way to do it. Another way is to use K2A.kr on the Phasor, write it to a control bus, and then you can get the control bus's value using Bus:get.

James

[bitbutter]

Yes, SendTrig is a good way to do it. Another way is to use K2A.kr on the Phasor, write it to a control bus, and then you can get the control bus's value using Bus:get.

James

Thanks, i'll look into that approach too.

One snag i've come up against trying the SendTrig method is that it's not obvious to me how i can figure out where SendTrig messages are coming from, in particular i'm not sure how i can get an OSCresponderNode to know which Synth instance is responsible for the SendTrig message it just received (because i'd like it to just respond to messages from one particular instance).

Maybe the control bus approach makes this easier (perhaps by getting each synth instance to write its phasor state to a different control bus, the bus number determined by synth arguments maybe).

I'm just thinking aloud, in case someone notices i'm barking up the wrong tree. Thanks again for the useful pointers!

[dewdrop_world]

The /tr message coming from SendTrig has 3 numeric values:

['/tr', nodeID, id, value]

If you have SendTrig.kr(someTrigger, 0, ugen) playing in Synth node 1000, the client would receive ['/tr', 1000, 0, (ugen-value)]

The format of all server messages (both sending to the server and receiving from it) can be found in Server-Command-Reference help.

James

[bitbutter]

Thanks James, that's useful to know. For the moment i'm having a go implementing a control bus approach. But i think i'm having a scoping problem.

Here's a class definition for an object that's in charge of updating the position of a horizontal slider based on a value it gets from another object (the reference to this other object is held in the variable source_model). This value it retrieves corresponds to the playhead position i was working on earlier (the phasor value).

The plan was to get the 'update' instance method to run repeatedly.

Code:

TKEightStepView {
var source_model;
var window=nil;
var slider=nil;

*new{ |w, src |
    ^super.new.init(w,src);
}

init {arg w, src;
window=w;
source_model=src;
slider=SCSlider(w,Rect(10,10,150,40));
SystemClock.sched(0.0,{this.update; 0.025});
}

update {
if(slider!=nil,
{var val=source_model.get_position;
slider.value_(source_model.get_position)});
}
}

But here's the error i'm getting when i try to use an instance of this class

Code:

ERROR: Primitive '_SCView_SetProperty' failed.
operation cannot be called from this Process.
RECEIVER:
Instance of SCSlider {    (1C6817B0, gc=40, fmt=00, flg=00, set=04)
  instance variables [16]
    dataptr : RawPointer 18F7F710
    parent : instance of SCTopView (1C694DD0, size=19, set=5)
    action : nil
    background : nil
    mouseDownAction : nil
    mouseUpAction : nil
    mouseOverAction : nil
    mouseMoveAction : nil
    keyDownAction : nil
    keyUpAction : nil
    keyTyped : nil
    keyModifiersChangedAction : nil
    beginDragAction : nil
    canReceiveDragHandler : nil
    receiveDragHandler : nil
    onClose : nil
}
CALL STACK:
MethodError:reportError   1651DC30
arg this = <instance of PrimitiveFailedError>
Nil:handleError   1651C4F0
arg this = nil
arg error = <instance of PrimitiveFailedError>
Thread:handleError   1651D630
arg this = <instance of Thread>
arg error = <instance of PrimitiveFailedError>
Object:throw   1651CAF0
arg this = <instance of PrimitiveFailedError>
Object:primitiveFailed   1651C190
arg this = <instance of SCSlider>
SCSlider:value_   1651C070
arg this = <instance of SCSlider>
arg val = 0
TKEightStepView:update   1651B950
arg this = <instance of TKEightStepView>
< FunctionDef in Method TKEightStepView:init >  (no arguments or variables)
Function:awake   16505D80
arg this = <instance of Function>
arg beats = 23390.649583926002
arg seconds = 23390.649583926002
arg clock = class SystemClock
var time = 23390.649583926002
After update: 188893

I thought this might have something to do with the sched task that calls the update method having been defined in the init method (a scoping problem?). Can you see anything obviously shady with this class definition?

[joshp]

Take a look at the 'understanding errors' helpfile from the main SC help page. This is a common one.

Hope that helps.

Josh

[bitbutter]

Ah yes! "3. Common primitive errors
- operation cannot be called from this Process."

I overlooked that before.

Thanks for finding a diplomatic way to deliver a deserved 'RTFM'