@Jona I read up on it and see what you mean about saving arrays inside patches. I appreciate it but it's not a great fit for what I'm trying to do. Thanks though

@seb-harmonik.ar I'll take a closer look at organelle does it - but I if I recall it doesn't actually use overdubbing, you just create new loops out of old ones, right? That still might give me a clue on how to buffer file loading, since it still has to solve the problem of immediately playing the files when you have just finished looping.

@Jona what object would take the -k flag. I'm not familiar? Is this soundfiler? Tabwrite? I'm having trouble locating it. I do like the idea of auto-saving my arrays though. And I don't mind only recalling the last saved state... This sounds very promising.

I didn't know about file. It looks perfect. I didn't even know about PD 52. I'm using purr-data nw.js version 0.24.5 on linux - mostly because it includes limiter~ and z~. It does not seem to have file. Maybe there's an update out there? Or, I could probably just pull in limiter and z to vanilla.

Does anybody know of a sample looper that uses soundfiler or readsf~ and writesf~ instead of arrays?

I am currently using arrays for my 16 track looper. For saving them to file, I was going to simply copy the array to disk, but it would be ideal if I could loop the sound files instead of the arrays. This would also free up a lot of memory. I'm currently running this on a 4gb rasberry pi, but it would be great if I could get this down to a 1gb pi so other people might be able to use it easier.

From what I can tell, the main problem with .aiffs is the save and load time. My program already uses an input buffer and an output buffer around the looping array, but not for purposes of giving the array time to save and load. It is also constantly reading and writing from the same array. I don't think I can do this with files, right?

Anyway, if anybody knows of an example program out there that successfully uses buffers to account for saving and loading times -- AND / OR -- that allows unlimited overdubs to the loops -- it would save me a ton of time trying to figure this out from scratch.

Thank you

@Jona Thanks! I didn't realize that. I can probably cook up a solution using that.

I know that soundfiler essentially reads and writes .aiff files by copying into and out of arrays.

Is there a way to delete files from within a running PD patch without using a dialogue box?

Here is the problem I'm trying to solve:

I have a 16 track looper which uses a combination of delay lines as buffers and self-overwriting arrays for the loops. I have 100 save slots where you can save tracks (copy the arrays to .aifff files), then load those .aiffs into the track arrays.

All of this uses hardware and does not use any screens, keyboards or mice. The problem is that those 100 slots fill up quickly, so I'd like to be able to delete the contents of slots -- again, this needs to be "automatic" without using any dialogue boxes or anything like that. It's easy to keep track of the names, they would just be 0-100.aiff, essentially. So I would know I want to delete 4.aiff for example. Is there a way to do that?

Thank you!

@bocanegra I spent a little time with this and got my head around it. I then put it in my looper to replace the vlines and it works GREAT. It took the attack from a dull 7 msecs to a nice crisp 1 msec. The attack on this sounds much more like the DL4, which was my goal (I love how that looper sounds). Thank you so much for both the program and for explaining it so clearly!

@bocanegra Thanks very much. I'm having a hard time wrapping my head around it at present, but I think if I mess with it I can get it.

I have a sample looper that is working just fine. It uses vline as a volume ramp when it starts and ends recording a sample. It uses a 7 msec vline. It does not click - however, I would love for it to have a super fast (but still clickless) attack when the sample is played back. However, when I drop below 7 msecs it sometimes clicks.

Would it help to use tabread4~ and an exponential curve instead of vline? (Kind of how Hanning windows work)?

These are LONG samples - up to 100 seconds, so I would need a way to only use the window for the first few msecs of recording.

Thanks!

I’m in the process of eliminating Comport entirely and using MIDI USB devices instead - same hardware but reprogramming the arduinos. I’m hoping it will make things faster for pure data but also hoping it will mean I can use those same hardware devices with other computers as MIDI devices that can be free of their parent so to speak.

Any thoughts on whether a rasberry pi running pure data will be faster handling incoming USB midi signals as opposed to two instances of comport?