Just posted this in the existing Euclidean rhythm thread in the technical issues forum, but, at the risk of redundancy, I thought I might also post it here for the sake of completeness. Please find attached my much-simplified (but functionally identical) implementation of the Euclidean rhythm algorithm. Hopefully the abstraction is reasonably self-explanatory.

http://www.pdpatchrepo.info/hurleur/euclid.pd

hi all,

I'm currently trying to figure out how to get an FFT 'freeze' effect to work in pure data - that is, to take and hold a snapshot of a particular moment's harmonic/spectral content. A Max version of what I'm trying to achieve is demonstrated nicely here:

Although I have a reasonable understanding of how FFT works, I don't have any experience whatsoever of the FFT objects in pure data, and at the moment I'm a little confused by some aspects of how they work. Consequently, I'm having some trouble getting this to work. One useful thing I have found is this post on the (very nice!) rumblesan blog: http://www.rumblesan.com/?p=223 . It describes and contains a patch to do exactly what I have in mind. However, the sound of the frozen version of the sound seems quite distorted, and not very faithful to the original sound - particularly when compared to the max patch shown in the youtube video above.

Does anyone know how I could improve the sound of this patch? Would fiddling with parameters like block size and overlap help?

Thanks in advance!
J

Hi all,

Preamble: I'm currently working on writing an external that implements the Perlin noise in pd. The Perlin noise is an algorithm for efficiently generating band-limited pseudo-random signals, and it's often used as a building block for creating somewhat random, "natural" looking visuals. But as far as I know, it's never been implemented in an audio environment, so creating an external for it for pure data seems like a fun experiment.

Anyway, the reason for this thread is that I thought it would be nice if all a patch's objects created from this external could share the same table of random "seed" numbers, so that the same results could be gotten from each of them. It would also be necessary for any of the objects to be able to update and reshuffle the table of values whenever a bang is sent to its "reseed" inlet.

I assume that this kind of data-sharing between objects from the same library is possible, because something similar must be going on with [send] and [receive], right? I also imagine it's got something to do with where you declare the data in the code, but that's as far as I've got. Could anyone point me in the right direction for this?

Hiya,

I just started using pd and have already made a couple patches that I'm pretty happy with. But now I am trying to make one of my synths polyphonic, and it seems that the nqpoly4 object is mysteriously missing from my library. Whenever I try and create it, the object stays outlined in red, as if it hasn't been recognized. But isn't nqpoly4 supposed to be in the pd-extended library?

Does anyone have any idea what is going on here, or how to fix it? (Failing that, are there any other objects for polyphony which I could try using instead?)

Thanks for your help!

You might have already tried it, but the included patch I07.phase.vocoder.pd (filed under pure data/03.audio examples in the help browser) is a fairly decent and relatively artifact-free timestretcher, in my view. Having said that, I can't vouch for how well it passes audio that isn't being stretched.

Are you talking about building a synth in pd, or sending midi messages from pd to control an external synth? I'm not 100% sure, but assuming you're talking about the former:

You might find that polyphony is hard to reconcile with the glissando idea, actually - many 'gliss'-type synths only allow this in monophonic mode.... The reason being, it's hard to specify which of the old notes you want to slide to the new one that has just been pressed. Nonetheless, it is possible; you should just be aware that that aspect might be tricky and/or involve some compromises.

Anyway, I think the [line~] thing would work, but here's how I would go about achieving a simple, monophonic version of this kind of thing would be with something like the following:

[notein]
|
[sig~]
|
[lop~ 2]
|
[mtof~]
|
(your synth here)

That's a pretty unconventional use of [lop~], the low-pass filter, so I'll take a moment to explain it. Basically, the signal from [sig~] jumps immediately to whatever midi note you feed into it. As far as [lop~] is concerned, this jump (discontinuity) is a mixture of many different frequencies. Since its argument is 2, it will only let through the frequencies below around 2hz... This has the effect that it slides to the new note slowly, in about half a second, or a little more. You can raise the amount of time a slide takes by lowering the argument to [lop~] to 0.5 or so if you like.

Hope that helps! Post again if you have any other questions.

You're correct that [tabread4~] includes interpolation for non-integral values of lookup, and is probably the correct thing to use here, although I'm not sure it solves everything that you're talking about.

Are you intending to loop the audio sample you're playing? If not, then you don't really need to worry about the interpolation points at the beginning and end. If you are, then I think there's an easier way to do it: just extend the size of your table by 2 points (I think?), and copy the contents of the first two data points into those newly-created last two. Then just use your table as before, remembering not to refer to the extra two points in your lookup - just use the original table size, before it was extended. Not 100% sure, but I think that's sufficient to ensure correct interpolation for looping.

Hope that helps with at least some of your queries.

Do you mean [tabplay~]? That's the one with a message-format in/outlet.If so, I'm not 100% sure, but I think there would be a small (on the order of fractions of miliseconds) delay, since messages are only processed between blocks (every 64 samples, by default).

You might be better off using a [phasor~] or a [loop~] plugged into a [tabread~].

I'm not sure how related this is (and I have to admit, like you, I'm also not completely sure what a 'bitwise granular synth' could actually consist of), but here are some good examples of 'musical' (well, arguably) use of bitwise operators, bitshifting, and related silly bit-twiddling: http://countercomplex.blogspot.co.uk/2011/10/algorithmic-symphonies-from-one-line-of.html

Should be possible to do something similar in expr~, although those specific examples might not translate directly, due to differences in samplerate and audio bit-depth between the two environments.

Yeah, I think in this case there are good arguments for rolling your own. Basically, whenever an object can be replaced with a single [expr], I'm inclined to make that replacement.