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.

Yeah, it's a shame. I suggest the best method for you may be to look at how many times each value repeats, and block them if they repeat more than, say, 5 or 10 times. I think that should be fairly accurate - maybe the best you'll get. Good luck!

Warnings aren't necessarily a problem - does the program run anyway? If so, you probably don't have anything to worry about.

To run pd as admin, enter:

gksudo pdextended

into a terminal window, or the 'run program' dialog box (not sure where to find this in ubuntu default setup)

Hey vandijckv!

That sounds like bad news - I suspect it is not possible to get my patch to help you. I guess that the hack does rely, as I suspected, on a weird quirk of my operating system! What operating system are you using, by the way? I'm on Ubuntu Linux.

The [moses 1] is because, on my system, the intervals [timer] reports are either 25 or 0. (I guess the fact that it outputs exactly zero rather than just a very small number is because it measures 'logical time' instead of real time?) It sounds like this is not the case for your system, so I think my patch won't be any good to you.

However, I suppose It's possible you might be able to come up with a similar fix for yourself based on the increased timing you observed when moving the mouse.

Forgot [abs~] wasn't vanilla. But [==~] and similar objects don't seem to be in my version of PD - do you know what the problem is there, by any chance, or how to fix em? They'd be handy objects to have available!

By the way, [*~ 1] is redundant in your patch, but I guess you already knew that and were maybe just doing it for the sake of clarity/symmetry.

[expr~] has an exp().

something like this seems to work for your case:

[inlet~]
| \
| [abs~]
| |
[/~]
|
[outlet~]

I think technically it should give a divide-by-zero error in the case where the input equals zero, but for some reason it seems to just give a zero out, which is what we want.

For what it's worth, I think there is a ==~ object somewhere, but possibly not in vanilla.

Mtof will work, but you were on the right track before that, too! Exponents are the way to go. A linearly ramping [line~] plugged into [exp~] will result in a 'perceptually linear' (i.e. same time for each octave) ramp of frequencies. How do you pick the correct values for [line~] to start and end its ramp at? Take the (natural) logarithm of the frequencies you want to start and end at.

If you're on linux (or mac os, I think) then you might be able to do something like sending [cd /your/wav/directory( followed by [ls( to [ggee/shell] to get a list of the files. There might be easier ways, too, though.

Well, I made it for myself anyway, so I might as well upload it: here's an updated version of the above that does the summing thing I mentioned also.

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