[PD] pause writing to delay line / hybrid of array and delay

[Max]

On 14.03.21 21:56, Alexandre Torres Porres wrote:
> Hi Max, I'm responding to an email from another thread, but I think it 
> belongs here :)

Sorry for the delay. I only see one thread - a Gmail issue?

> 
> On 05.03.21 17:45, Max wrote:
>  > It finally came to me that when I put tabwrite~ into an abstraction I
>  > can pause the array writing by stopping audio processing in that
>  > abstraction using switch~. It also can loop by writing into the table
>  > like into a ringbuffer. The other half of the issue is to also take
>  > account for the write pointer in the player. I'm using sig~ 1 into
>  > rpole~ 1 (Thanks José de Abreu) and using that in the deque reader.
>  > The accompanying dequread4~ uses that write head position as an offset
>  > to the table (modulo the table size).
>  >
>  > it's vanilla
>  >
>  > it may have stupid problems / errors, please let me know if you find any.
>  > There is an error in the Pd console
>  > no such table ''
>  > but that doesn't seem to affect the functionality and Pd can't trace
>  > that error.
> 
> So, I've seen your last revision of the patch and I'm not sure I get how 
> it is useful or why you need it like that. And now I'm really just 
> curious and interested in the applications of this.

I have a kind of a sampler which I control with a sensel morph (btw, I'm 
using the 14 bit MIDI mode of the sensel, not the sensel object, because 
the MIDI is rock solid and the object isn't).
Anyway, the sampler records continuously the last ~7 seconds and as soon 
as i put a finger on the sensel I can mess with this buffer. If I let 
go, it continues to write into that buffer.


> It's nice that it is all vanilla, but it is still very limited as I see 
> it. You don't have sample accuracy for start writing and stopping or 
> pause/continue.

I just need block accuracy for my application.

> And I see that the looping (or ring buffering) isn't perfect either 
> because of this sample accuracy issue. You're analyzing to see if your 
> signal counter goes over the array size but the resulting bang comes out 
> after some samples, so... clicks.

that may be, but irl i'm not too bothered by it because the whole thing 
has a glitchy aesthetic anyway, so that can stay.

> Anyway, this approach of yours is quite similar to what I did here with 
> objects from cyclone, have you checked it? Doesn't it do the same thing? 
> Does it fail for your needs somehow?

I could not figure out how that patch works, which toggle is supposed to 
do what and I would have to read all the help files for all the 
unfamiliar cyclone objects to understand what is going on. It feels out 
of control for me, for convenience I rather use the patch I made myself 
because I still know what's going on there. I need to fully understand 
it to feel confident that I can fix it if a problem should arise.
I think that's why many Pd users start to write their own abstractions 
rather than using someone else's (Pun not intended).

> I just made an update to the ELSE library (version beta 37) and now I 
> can do the same with objects from ELSE, so I'm attaching it here.

cool, but same as above applies there.

> Note I've also added a new [del~] object with a freeze option and also 
> included that functionality in [ffdelay~], but I guess that's something 
> not really appropriate for what you want, what do you say?

I have a table based granular sampler so to speak - 10 fingers on the 
sensel = 10 grains playing. I would have to re write that to play from a 
delay line instead of a table. Probably possible, but I rather not touch 
that part which I'm already happy with :)

Thanks for your commitment Alex. Even though I can't use it right now it 
truly is appreciated!

Max