I’m using the ‘Granular Freezer’ patch for a sound installation. It’s working great but i’d like to be able to edit it in 2 ways:
Can anyone help? I’m useless on PD so would really appreciate any help with this!
I can surely help you but 8 seconds ain’t gonna happen. The buffers in organelle to sound nice MAX OUT at around 4seconds, so 2 is preferred which is certainly more than 500 
I wish i could tell everyone that loooong sampling has to be finessed just making those buffers larger i have found turns into clicky hell.
Can Organelle not load larger files than 4 seconds? I thought this was related to the memory, which is plenty in Organelle.
Are there other limits that one should be aware of?
Thanks, Jaffa
Well, yes and no… Pd can load samples up to 90 seconds (which I think the maximum allowed). The patch Nori Sampler records, saves and loads a 60 second sample. But there are a couple things to point out.
First, saving and loading long samples can start to take a while so a patch might load slowly (although for a granular patch that doesn’t save or load the sample buffer this isn’t a problem). The second is what @shreeswifty pointed out: in Pd you will start getting aliasing (digital distortion) if you play back samples longer than a few seconds. Sometimes this might not matter, for a crazy recording patch like I Take Up where the buffers are pretty long but you don’t hear the distortion because everything is wild anyway, but for a granular patch it will probably be less desirable.
These issues can be worked around, but often takes time to get it right. The Nori Sampler that uses the 60 second buffer uses a workaround to avoid the aliasing, but it is complicated and hard to work into other patches.
these limits, are we talking about limits imposed by tables, tabread/write ?
I assume if you write an external, then there are no limits, other than those imposed by the operating system… e.g. I could imagine an external that would read data in blocks off the disk, such that it didn’t cause audio glitches, in particular using non-blocking io.
also , can you explain why there is aliasing with longer samples?
Thank you for the clarification. So 90 seconds is the same as Axoloti. And Axoloti only has 8 megs of SD-ram. So there must be introduced some other “limits”?
@thetechnobear you know a lot more about Axolotis deep development than i do, maybe you know something about this?
I have been thinking about making some crazy *** dj system for the organelle(when I get one soon) and for this, 90 seconds pr file is not enough. SO just trying to find out what is plausible and not 
Thanks!
Yeah, this is why I’m asking questions…
I’m not sure if the limits above are referring to pure data limitations and/or this granular patch.
Fundamentally, I can’t see why c++ code in an external could not use ‘arbitrary’ amounts of memory, threads and stream data from an sdcard/USB - of course there are some limits ( hardware/ Linux)
Similarly I’m a bit confused about the aliasing being related to sample length, I would not have thought this to be the case … and clicking similarly sounds like windowing rather than length
BUT it could be this is all related to the granular patch rather than samples in general.
But I’m a PD newbie so perhaps there is something about its externals… though if so, I’m sure someone has coded others!?
Me too.
About the length, I found this link where PD’s maximum sample length is discussed:
Katjav says this in the last comment in the thread:
You can extend the maximum array length to fill with samples from an audio file with flag -maxsize to the soundfiler object. So if you use the [openpanel] object to find the soundfile, the message could be like this:
[read -resize -maxsize 4.3e+07 $1 soundfile-array(
About the aliasing on long samples. Dunno anything about that. I dont experience that as a problem on Axoloti.
The 90 seconds is the default max array size, but there might also be a message to enlarge it. And that is for a single array, so you could have many 90 second arrays until you run out of RAM.
The aliasing comes from not being able to accurately index a large array with 32 bit float (default data type in Pd). Check out help patches B15.tabread4~-onset.pd and B16.long-varispeed.pd from the Pd help browser. From the help patch:
Pd is usually compiled to work on 32-bit audio samples. These do not, in general, have enough precision for use as indices into an array of more than about 32K samples. This is because the mantissa of a 32-bit floating point number has only 24 bits, out of which you would be using 16 bits or more to address a sample more than 32K into the array, so there would remain 8 or fewer bits to supply the fraction. In the most extreme situation possible, the sample could contain a Nyquist frequency sinusoid and the output would then have only about 8 bits of accuracy!
Thank you for the detailed info @oweno , very useful/informative for a PD newbie like me
one thing, from the original OP, its was discussing granular freezer… that seems to use delays (delwrite/read) rather than tables… are these limited in size in the same way? d_delay.c seems to show it does not limit.
also would delread have the same issues as tabread? id think not, unless your were continually varying the delay time on a very large buffer… (and if you do that your doomed, since there does not appear to be an onset equivalent)
onsets… interesting, seems complicated, due to the way they have decided to mix a sig~ input and a control rate onset… so you need to be careful of the timing. I guess this was to avoid the cost of having an extra sig buffer for the onset input.
(which when your dealing with low buffer size is not such a big deal)
Oh yeah, forgot this was about granular freezer. I don’t know about the max size limitations of the delwrite / read objects, but I’d expect the same sound quality issues when the buffers get long.
Increasing them to 8 or 10 seconds may be fine though… In the end its more a matter of taste and depends on context. I’ll try making this patch with longer delays and seeing what happens, if only to get some sound examples of what we are discussing!
been meaning to try this out for a while to see what it sounded like, after all the talk about digital distortion. I increased grain size to 8 seconds (and also increased spread) and pitched the whole thing down 1 additional octave.
Actually couldn’t really notice any distortion, if the times get longer it might be worse, but seems to work fine at 8 seconds. Thanks for the suggestion @jamiecooksound for the suggestion, this is a different beast entirely!
Holy heck 
Wonderful!