resize does create a "crackle" in my experience too.
One work around in your case perhaps would be to use delwrite~ and delread~ in aloop, something like this: liveloop~.pd
When you call this abstraction you need to specify the buffer size in ms which will be your maximum loop length.
I'm not exactly sure what you want to do but I hope this helps somehow
[wendy] maps incoming notes onto scales constructed around equaly divided ratios that can be other than 2:1 (the octave), allowing for example pure fiths, at the cost of an imperfect octave, a cost which I'll gladly pay. As Wendy Carlos said: "That's one of the things you aren't suppose to do, which is exactly why I did it!"
It can be used to have any edo scales if desired
see help file for more info
vdisk~ uses [readsf~] in conjunction with [block~] and [tabwrite~] to read a file from disk at any pitch/speed.
Usefull for situations where you need to load very quickly any soundfile from any folder and want to read them at any pitch.
I made this because I needed it and some externals such as [sfread2~] from moonlib tended to crash pd on my system, so I decided it wasn't reliable.
@Jona , Here are some examples:
1: I just write series of zeroes and ones and then do a [select 1] to trigger samples and stuff
2: I write gain values
3: I write notes or frequencies, such as 60 61 65 ...
4: I use the second outlet to have duration value (simply a time until next beat) and read a sample for that period of time
But then you can use it in any way you like
The tuplex abstraction is a sequencer that works on the principle of tuplets in music theory, that is to say division of a time unit.;
It works around a [delay] object that is periodicaly syncronized to a master metro, so as to never go noticeably off-beat even with low precision.
It allows to write rythms as it follows: 16(1 0.8 1);
This is relative to the metro time setting and means that a period of 16 metro time units is divided into 3 beats.
You can also write 16(1 0.8 (1 1)), which means that the third beat itself is divided by 2
You can have a succession of such expressions as it follows: 16(1 0.8 (1 1))-7(0 0 1 0)-3(1 1)
Now it works fine for what it does but I find it inelegant:
You can only have on set of parenthesis inside another, what would be really cool is something in which you could have an infinite number of sub-parenthesis such as in the [expr] object like this: 64(1 0 (12 13 0 (0 1 (0 2) 4)) 1), but I have no programming knowledge to do this. I've spent a lot of time thinking about this but couldn't find a solution. If any-one has some ideas as to how to do this, please shoot!
Hi, I have a question concerning the [pd~] object:
How can I benefit from using it? I'm quite confused.
I did a test running a very cpu hungry patch in a sub-process and putting a reverb in the super-process. My preconception was that the audio drop-outs would occur only in the sub-process and could be heard in a nice clean reverberated way, but it affects everything, I have audio drop-outs wether I move objects with the mouse in the super-process or in the sub-process.
When I checked the cpu load was 90% in the sub-process and 10% in the super-process.
Is that related to the way JACK works? or a computer? Please excuse my complete ignorance on the matter.
I'm running ubuntu 14.04 with JACK on a Intel® Core™ i5-5200U CPU @ 2.20GHz × 4.
Hi all! I'm new here, I just want to start contributing to the pure data society by posting this abstraction I made. It's basically a multi-band panner, that pans high frequencies stronger than it does with low ones. I did this intuitively (knowing that high frequencies are more directional), so it's very unscientific, but it sounds good to my ears. It sounds more natural than a regular one-band panner and works well with rich sounds, not very relevent for high pitched percussions and stuff though. Anyway let me know if you think the frequency bands and ratios should adjusted otherwise or whatever
mono input version:
you need [pan~] for the abstraction to work, was too lazy not to use it, but a signal controled one could be better