Puredata! (thread)

[chapelierfou]

I am currently re-writing from scratch my (originally patched by @stevieraysean) dj-mlr app in Pure Data 0.49 vanilla for an educational purpose but also because I hope to be able to rock it on an Organelle M (soon to be arrived).
I must say that I’m enjoying the journey a lot. At first I felt like PD was messy and ugly, which is true, but it also forces me to patch much more cleanly than I do in Max, with all its fancy objects. I’m learning a lot from this experience, and I realize that so many objects can be replaced with abstractions.
Just wanted to share my enthusiasm, if it can encourage people to dive in it. Being able to run on Bela, Organelle, RaspberryPi, Nebulae, etc, PD seems still very capable today.

[nurse_plissken]

hey folks, I recently started poking around pure data with the goal of building sequencers. I’ve been having a lot of fun figuring things out, but one thing I’m stuck on lately is clock division. My I’ve gotten some good results screwing with metro and tempo, but one thing I can’t crack is, when changing ratios, the clocks get out of sync(hitting on the up beat, quarter beat, etc). is there a way to quantize multiple metros together?

for further detail, what I’ve got right now is a toggle connected to a send. multiple metros receive the send so they all start at the same time. then, I use different divisions on the individual metros. this quickly gets things on the same page but it also isn’t a good way to change stuff in realtime.

I took a stab at using a phasor~ for a clock source, but couldn’t figure out how to derive bangs from it as an expr~ won’t bang for me.

am I barking up the wrong tree, or just missing something obvious here?

[jwudel]

Been some time since I’ve played with PD, but one thing you might try is using some kind of clock divider to get multiple rhythms from one metro rather than trying to sync multiple metros. Set a float to go up by one on each bang and wrap using a modulo. I think Route or Select would give you a bang on 0? Then you should be able to change the value of the modulo to get different clock divisions.

[Oootini]

Check out the clock, div and multiply objects in automationism. Automationism is just really well patched and easy to read/understand.

I’ve just been hacking a CC div/multi object actually.

[fahmi_m]

My generative dark ambient / drone sound experiment with Pure Data (Automatonism patch):

[nurse_plissken]

thanks folks!

I got something going with route last night for division, but digging into the automationism multiplier taught me more than i bargained for. This is giving me a lot of good things to work with. Thanks for the suggestions!

EDIT: tonight I got a simple 8 step ratcheting step sequencer going. I’m primarily interested in using PD to sequence, so this was a big win for me.

[chapelierfou]

I’ve read somewhere an advice (in a Max MSP tips and tricks document) : “use only one metro”.

Although it can sound a bit too radical, I think it’s a great advice to spare you from weird timings.

[nurse_plissken]

that makes sense, it took me a little bit to figure out why I was having some issues with that. I’m working my way through the help files in PD still and trying to learn new objects(timer was a breakthrough) so hopefully I’ll get to that level soon!

[chapelierfou]

Hi there, I’m stuck with a problem and would be more than happy if someone could help.
Hope you don’t mind if I re-post my thread on the puredata forum :

I’m having headaches trying to figure out a (stupid ?) problem in a patch I’m working on, and I thought maybe it would be obvious to someone here, who knows ?
Basically, I’m working on my own MLR-inspired patch for monome grid. It’s a sample cutter that accesses 16 start points in a sample loop.
Where I’m struggling is at “inner loops”. The idea is that when you hold a first button and press a second one, the file loops between these two points. If only one press happens, the whole file loops, starting from here. It works but the playhead “jumps” when the end point is pressed. This is what I want to avoid.
I guess something should be corrected in my [scale~] patcher, or something like that.
I also tried to hold the second press into an [f] and trigger at the end of the [phasor~] loop (using cyclone [edge~] and [onebang]) but no luck.

Here’s a patch to illustrate the problem.
Any help would be awesome.

Cheers,

LouisMlr_work.zip (4.7 KB)

[Jonny]

Have you taken a look at what @josephbranciforte did with his toolset? His patches use pd-extended, but you could probably borrow most of it if you’re using cyclone as an external.

http://josephbranciforte.com/pd.html

[chapelierfou]

Yes I have, but his inner loops seem to suffer from the same bug. (Or was there another problem with inner loops ? cant’s remember, need to check). Thanks for the answer.

EDIT after checking JBLR patches: the problem with JBLR’s inner loops is that the first press doesn’t force the playhead position and doesn’t not disable the inner loop. In fact nothing happens until you release the second press. This is very different from the feel of the original mlr and I suspect that the whole process is quite different, so not really re-useable.

[chapelierfou]

I still can’t figure it out… Any help would be appreciated.
I guess that the phase of the [phasor~] needs to be sampled when a loop is triggered and adjusted to the new loop.

[ermina]

maybe toggle between two phasors, one every other loop, such that rescale actually happens only on unused phasors. (i looked into your patch quickly yesterday but that is too much logic for me to handle in pd).

[vdof]

and for what it matters, all those little annoying things that before were stopping people from moving from Max to Pd, have been almost all removed.
See infinite Undo/Redo, keyboard shortcuts (I think more advanced than the ones in Max), etc.
Worth having a look at Pd 0.50 as well

[zzsnzmn]

I had an old tape-deck-y app that I think did something like this— I’ll try and take some time this week to get acquainted with the patch you shared to see if there’s anything from that that might work.

[chapelierfou]

Many thanks to you for the answers.
I think I need a fresh brain. I’m so tired these days. I’ve got this thing happening where I know it’s a relatively easy issue but I can’t focus properly.

[vdof]

Hi,

In my opinion in Pd (and other “audio programming languages” with few exceptions) you can have issues of this kind when you use audio objects controlled by non-audio objects. In this kind of scenario usually or you end up having glitches (ie when changing parameters) or having things going out of sync.
I personally think the best is to try to do as much as possible in the audio domain so to have more accuracy and less “sync-related problems”.
I downloaded the patch and made few changes. In a nutshell now you don’t have a [phasor~] reading the buffer, but an accumulator instead (ramp from 0 to sample_size_in_samples). Plus all the parameters get updated in accord with a sync rate you can define. More info in the patch.
Hope this is useful in some way.Mlr_re_work.zip (2.9 KB)

[chapelierfou]

Thank you very much for this. It’s way more than “a few changes”.
It’s a lot to process for me but I already learnt some precious stuff from your patch. I’ll study it deeper asap.
Unfortunately, my original issue seems to be unsolved : when you set up a loop, the playhead jumps to another location. I wish that only the first press makes the jump, then the second press just sets the loop.
Anyway, thanks again.

[vdof]

about having the second press only changing the loop, this raises a couple of questions:
is it important for you to stay in sync? if yes in what way?
what should happen if, while the loop is playing, you set the end point to a value that is behind the playhead?

[chapelierfou]

Here’s the behavior I’m trying to achieve :

• A first press always triggers the according position. (no second press is needed, it happens only when holding the first press and hitting a second one. This part I have it sorted)
• A second press smaller than the first should be ignored
• A second press behind the playhead could either wait for the “next pass” or simply be ignored (in practice they with be triggered quite fast)
• When a second press happens, no jump in the sample should be heard. (this is the main issue that I’ve been trying to fix. Basically the logic would be : make a snapshot of the playhead position, instantly remap/scale it to the new range)
  I need to get back to how it works in Max/MSP versions of MLR, but I suspect that it might be quite different since they work with [groove~] which is so much easier to handle in my opinion)

(Here’s an example with monome control of the first row Mlr_work 11092019.zip (37.9 KB) )