@whale-av Thanks for this! it does successfully rewrite the cc values but no other midi info from my electric drum kit is going into the software. Im using loopbe1 as the input for the drum software / output for pd. Very new to pd so not really sure at all what's going on, please would you be able to help me diagnose the issue? thanks
here's a screenshot of the drum software midi input, no other drums are being registered

@jameslo said:

This may be complete BS, but here goes: when I convolve a 1s piano chord sample with 30s of stereo white noise, I get 30s of something that almost sounds like it's bubbling, like the pianist is wiggling their fingers and restriking random notes in the chord (what's the musical term for that? tremolo?). It's not a smooth smear like a reverb freeze might be.

If you are just doing two STFTs, sig --> rfft~ and noise --> rfft~, and complex-multiplying, then this is not the same as convolution against a 30-second kernel.

30-second convolution would require FFTs with size = nextPowerOfTwo(48000 * 30) = 2097152. If you do that, you would get a smooth smear. [block~ 2097152] is likely to be impractical. "Partitioned convolution" can get the same effect using typically-sized FFT windows. (SuperCollider has a PartConv.ar UGen -- I tried it on a fixed kernel of 5 seconds of white noise, and indeed, it does sound like a reverb freeze.) Here's a paper -- most of this paper is about low-level implementation strategies and wouldn't be relevant to Pd. But the first couple of pages are a good explanation of the concept of partitioned convolution, in terms that could be implemented in Pd.

(Partitioned convolution will produce a smoother result, which isn't what you wanted -- this is mainly to explain why a short-term complex multiply doesn't sound like longer-term convolution.)

If I'm right, I think I should be able to increase the bubbling effect by increasing the volume variation of each frequency and/or making the rate of volume variation change more slowly.

Perhaps... it turns out that you can generate white noise by generating random amplitudes and phases for the partials.

(One thing that is not correct is that the upper half of an FFT frame is supposed to be the complex conjugate of a mirror image of the lower half: except for bins 0 and Nyquist, real(j) = real(size - j) and imag(j) = -imag(size - j). I haven't done that here, so it's quite likely that the non-mirrored mirror image neutralizes the control over randomness in the magnitudes. But I'm not that interested in this problem, so I'm not going to take it further right now.)

[lop~] here was a crude attempt to slow down the rate of change. (Note that I'm generating polar coordinates first, then converting to Cartesian for rifft~. The left-hand side is magnitude, so the lop~ is here but not affecting phase.) It doesn't make that much difference, though, if the phases are fully randomized. If you reduce the randomization of the phases, then the FFT windows acquire more periodicity, and you hear a pitch related to the window rate.

Anyway, perhaps some of this could be tweaked for your purpose.

hjh

"Easy," not really -- because the meaning of byte 'n' depends on what was byte 'n-1'. The current received byte has to set the routing for the next byte, which is a bit outside of normal straight-shot patching.

However I tested this with some simulated messages (including running status bytes) and it does seem to parse them out correctly. You could extend it for other message types too, but I don't have time to go further than this.

23-0916-midiin-state-machine.pd

hjh

@ddw_music actually, it is considered a bug if it's different every time you open pd. The rationale is that the behavior of a patch SHOULD be completely reproducible if desired (and that's the intent).

really, the meaning of the term 'random' mainly means having a certain statistical distribution. It doesn't necessarily mean 'different every time' or 'nondeterministic'. Even the term 'deterministic' is questionable: does it mean causal, or predictable? because any source of 'randomness' would be causal: chaotic doesn't necessarily mean non-causal.
Getting down to quantum systems things become a bit more controversial but imo simply not being able to make a prediction (determination) doesn't necessarily imply that some mechanical result didn't have a specific cause. (bohmian mechanics illustrates this)

@JoshuaACNewman A while back I was wondering about the relationship between FFT coefficients and the RMS amplitude of the input signal, and as a side project built something that did the inverse FFT by adding together the sines and cosines term by term to reconstruct the original signal. I wanted to test if I really understood what the coefficients meant and came up with an interesting animation. Maybe it might be useful to you? manual inverse FT 3.pd

Definitely check out all the I series Audio examples in the help system, that's mostly where I learned the practical FFT stuff from. Something that was hard for me to figure out about the real FFT is that it really only spits out the terms 1 to N/2+1, because the terms in the upper half are negative frequencies that are related to the positive frequency terms in the lower half. Term 1 is DC and term N/2+1 is Nyquist, and neither of those have negative frequency cousins in the upper half, so their coefficients represent the whole amount of those components, whereas the others only represent half (being split evenly between positive and neg frequency terms).

I hope I'm not making things more confusing.

@JMC64 said:

Yes it works very well. I own 2 of them. It also react very well with OSC protocol. I made a Drum machine based on it:
The interface is on my main PC developed in Python + WxPython and the Terminal module is in my rack.. I have a fully flexible drum machine. I can share the patch + code if anyone is interested.

Hi, I am exploring this now, looking at the terminal tedium code.

I wish to accomplish a very simple thing, just add a PIR sensor and get the reading in to Pd.

However I would like to add this function to an existing RPI OS (Patchbox Os) already set up to run a specific Pd patch using a multichannel USB card and I am a bit worried that if I just dive in and follow the instructions for setting up tedium on linux I will mess up the OS configuration.

Could you give me a hint on where to start?

this one is so basic that i couldn't even be bothered to take a screenshot of it.

it's a drum-kit consisting of a kick drum, a snare drum and a hi-hat, made from a bunch of [phasor~] objects and filters.

bang and drum.

there are no controls on the outside, but you'll find sliders to adjust on the inside.

made in purr data but should be vanilla enough to run anywhere

picodrumz.pd
picodrumz-help.pd

Hi Everyone,

In the last year I have recorded a few tracks using Pure Data and I am exporting them into Logic to mix them. I notice that the BPM tempo wavers. For example, if I have a tempo of 150 bpm, when I export the tracks to Logic it might have a tempo of 149.82 for a few bars, then 149.91, then 149.81, etc. it always goes a little slower in a seemingly random way. Over the course of a large number of measure it is way off the tempo. I know this because I have a kick drum pattern that always attacks on a certain beat and I can see it’s off.

I have heard a few other people mention this issue, but it has never really been an issue for me until now. Does anyone have any strategies for dealing with this? I am sequencing a few elements and I want them all to be in sync, drums, a bass part, etc. And all the various drums themselves, like a kick drum, snare drum, hi hat, etc.

I am using regular metro objects all starting from a single message that is sent to the different metronomes. Should I try and use all audio rate timing or something similar?

It is not easy to notice the tempo wavering by listening, but sometimes I think I can notice it too, and it’s sort of weird rhythmic feel as well.

Thank you in advance for any advice.

Hi,

About a year ago I started to learn a bit pure data in order to create a patch that would act as a groovebox and that should perform on limited cpu resources since I want it to run on a raspberry pi. First I tried to make somekind of fork of the Martin Brinkmann groovebox patch, even if it allowed me to learn a lot about data flow I didn't went to the core of the patch tweaking with sound generation. This led me to end this attempt at forking MNB groovebox patch because even if I could seperate GUI stuff from sound generation and run it on different thread ect... I couldn't go further in optimization in order to reduce the cpu use.

Then a few weeks ago I decided to start again from scratch my project and this time I wanted to be more patient and learn anything needed in order to be capable of optimizing my patch as much as possible. After making a functional drum machine which runs at 2/3% of cpu with 8 different tracks, 126 steps sequencer, a bit of fx ect... I tried to find synths that would opperate well aside the drum machine. And I basicly didn't find any patch that wouldn't use massive amount of cpu time. So I created my own synths, nothing incredible but I'm happy with what I got, though I noticed some aliasing. I read a bit the floss manual about anti aliasing and apply the method used in the manual(http://write.flossmanuals.net/pure-data/antialiasing/), it work well but my synths almost trippled their cpu use, even if I put all my oscilators in the same subpatch in order to use only one instance of oversampling.

I didn't tried to oversample it less than 16 time but since oversampling is so cpu intensive I'm wondering if there's no other option in order to get a good sound definition at a lower cpu cost. I'm already using banlimited waveform so I don't know what I could do in order to limit the aliasing, especialy for my fm patch where bandlimited waveform isn't very useful in order to reduce aliasing.

Since I want to have at least 4 synth track with some at least one synth having 5 voice polyphony I want to know what the best thing to do. Letting FM aside for this project and use switch~ for oversampling 2 or 4 time my synths that use bandlimited waveform ? Or should I try to run different instances of pd for each synth and controling it from a gui/control patch with netsend(though it wouldn't bring down the cpu use at least it would provide somekind of multithreading for my patch) ? Or is there another way to get some antiliasing ? Or should I review lower my expectation because there is no solution that could provide a decent antialiasing for 4 or more synth running at the same time with a low cpu use in pure data in 2021.

Thanks to everyone that would read my topic and try to give some advice in order to get the best antialising/low cpu use solution.

So I've got a number box triggering a basic drum machine that I found on YouTube. Essentially the number box going into a gate object, which then only triggers whatever comes from the corresponding outlet. However, my problem here is with the looping of the drum pattern; it plays one loop of the 8 beat sequence perfectly, then stops on beat 4 of the second loop and restarts. How do I get this looping continuously until the number box changes and triggers a different output?
Patch: red dots trigger drums.pd
Video demonstration: red dot triggers drums.mp4