I have made a nice drum machine in PD with x0x style data entry but I would like to be able to just tap in patterns on the keyboard like you would on an MPC or similar.
Has anyone made a patch with data entry like this? Where you can tap in a rhythm and it gets quantised and stored in an array. Trying to invent a way to do it with various quantise options.
I suppose it's going to raise a lot of questions about storage too….. like if I allow 32nd note quantising and triplets then I'll need a lot more than 16 steps per sound in my array. Should I think about a different data structure? At the moment I have an array with 16 on/off entries for each sound corresponding to 16 steps in the bar, x100 patterns. Just make it bigger? Or go to some kind of list which includes timing info?

@nuromantix This was posted a few days ago on the forum........
http://forum.pdpatchrepo.info/topic/9906/click-tracker-version-1-4-is-out
Maybe you could build a patch that translates your patterns and saves them in such a format.
Yes.... you would need a pattern per instrument but........
The saved file format that they are using is quite sparse......... as it contains some timing info.....
David.

@LiamG the more I think about it, the more I don't see what you are gonna do with that list of events once you have it. Assuming your recorder is looping, you are gonna have them very likely out of order and possibly being added to a list already recorded. How are you going to play them back? I just can't think on efficient way to do it. I hope you can think of one!

The more I think about it, a big array seems the way to go because storage is cheap nowadays and timing is the most critical thing in a drum machine.

Just did this, might help you, I don't know. You just have to type one of the three letters E, R and T. You can approximate, in milliseconds, it gives you a margin of error. It takes "off beats". You could add further quantization, you would just have to modify the expr object following the same logic. You would also have to adapt the size of the array.
ert.pd
Lucien

@norumantix I'm using lists because I'm saving this (and a lot of other information) in the creation argument, but you're right that arrays are better for normal use. Still, the basic design is very simple. quantize.pd

@LiamG Don't you think it's a problem if notes just before the beat are interpreted as from the previous beat?

You can build an offset using a couple more arithmetic objects: quantize2.pd

Thanks everyone. Got my head round the concept now!
LInked list seems the way to go.

@djpersonalspace said:

Hi sorry to bring up an old topic, but just wanted to be clear. The offset is to allow you to basically key in the desired midi notes to the array before they are played. So that you can hear them as you play them as well as storing them for the next loop yes? Struggling to get my head round the best way to do this..

Also, where do the linked lists come into it? I cant see any list objects in the patch?

Sorry if Im being thick just learning pd

Thanks in advance

It is just the same as
https://forum.pdpatchrepo.info/topic/12387/quantising-in-real-time-for-step-sequencer/4
just smarter and shorter.

There is also shown how to read the array in steps with [tabread].
You can implement midi stuff with objects like [notein] [mtof] [ftom] ect.
Store a higher range of values, instead of 0 and 1 only, as it is done here.

Understand [trigger] [t] and [float] [f].

I would highly recommend you to go through the tutorials and example-patches of PD!