sfplay~ position outlet issue

Oct 13, 2008 at 8:58am

sfplay~ position outlet issue

Hi there,

I am trying to use the position outlet of sfplay~ to detect the end of a loop (when using “loop 1″, the right outlet doesn’t provide a bang). Of course, it is easier to retrigger manually using the bang, still I am interested why using change~ or delta~ doesn’t work.

Pls see patch below, on the left hand side, I am using a dummy signal (increasing and decreasing), the buttons are triggered properly when starting to ramp down. It just doesn’t work with the signal that the 3rd outlet of sfplay~ provides. any idea ?

nick

– Pasted Max Patch, click to expand. –
#40311
Oct 13, 2008 at 2:05pm

I can’t reproduce that. It seems to be working for me, both the [delta~] and [change~] buttons are triggered when the sound file reaches the end when looping is on.

lh

– Pasted Max Patch, click to expand. –
#142467
Oct 13, 2008 at 6:09pm

that’s weird, it should behave as you said. Still I copied the patch *unchanged* into a windows (5.0.4) and mac environment (5.0.5).

In both cases, for some odd reason, the buttons are triggered continously although edge~ should only detect zero to nonzero transitions (apart from the ever increasing signal anyway). Printing out the edge~ output shows continous bangs.

I must be making some really stupid mistake.

nick

#142468
Oct 13, 2008 at 6:18pm

Try checking that you don’t have any third party externals or abstractions with conflicting names in your search path. Other than that I’m not sure what to recommend.

lh

#142469
Jan 4, 2013 at 1:59pm

I’ve tried both solutions in this patch, which work if I create a new patch from your compressed info. It dlesn’t in mine… I’ve included the whole stuff so you can tell me if there’s something wrong elsewhere.
Could you also tell me what the O argument in sfplay stands for ? I can’t get it from the help file.

– Pasted Max Patch, click to expand. –

`

#142470
Jan 8, 2013 at 6:03pm

Nobody ?

#142471
Jan 9, 2013 at 2:45pm

I can’t reproduce your problem either (max 6.0.8, os x). Both methods are producing bangs. Luke’s suggestion is a good one, and if you haven’t gotten anywhere from that, you might want to consider a reinstall.

The second argument, btw is the size in samples of the buffer that sfplay~ holds internally as a kind of preroll, so that it will immediately start playing, rather than delaying a bit as it loads the first bunch of sample vectors from disk. Check out the buffer_size tab in the sfplay~ helpfile, and at the ‘Arguments’ section of the reference file.

M

#142472

You must be logged in to reply to this topic.