monohusche

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 ?

sfplay-position-outlet-issue

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.

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.

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.

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.

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.

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.

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.

sfplay~ position outlet issue