@Enkerli I'm really glad it helped. I see you have made really big progress in your project, I'm somehow proud of it, turns out that I'm not so bad at teaching as my sister says! :D
Jokes apart, I'll check your patch as it intrigues me quite a lot. If I can help you with the note off issue I'll let you know, but since I'm a bit busy with university at the moment I'm sure you'll find a solution before I can even give it a look.

I've been working on a chord generator some weeks ago. As soon as I make the help file I'll publish it here in the "abstractions" section so check it out. Your feedback will be enough to pay me back

@Enkerli Hi there.

Actually when you trigger a note your program sends out 7 notes:

• 1 - the note you actually played.

• 2 - the 3 notes coming out of the [+ ] objects, which are the note you played (in the hot inlet) summed to the last value you put into the right inlet (cold one).

• 3 - the 3 notes coming out of the [+ ] objects after the bang, which are the last value you put into the left inlet (the note you played) summed to the new value they received into the right inlet after [sel].

This is because you are using the note you played as a trigger for 3 different things, that are [noteout], [+ ]s and [mod 12]. You should avoid multiple connection when not needed and should be aware that every "number" you send acts both like a number and a bang. Also, be aware of the difference between cold and hot inlets, the first are just "memory", you put something in there and will remain there until the output is triggered, Usually this happens when something goes into the hot inlet, it may be a number, a symbol or a simple bang. Use the [trigger] object to force a bang into the hot inlet when you input something into the cold one.
I modified your patch and commented each solution, give it a look and everything will be clear

chorder-solution.pd

Hi everyone,

First of all, sorry for my bad english, I'm italian. This is the first GUI abstraction I share so hope you'll enjoy it. I've been using Pd for a little more than one year, so maybe this is not the most optimized piece of work you'll find around, but it surely does it's job.

I created a piano layout with 88 (piano keyboard) or 128 keys (midi range) that shows the notes played by a midi keyboard or something similar. You just need to input messages to one of its 4 inlets containing one or more couples <note velocity> e.g. you can pack the 2 outlet of [makenote] or [notein] or just simply a message such as |60 40, 64 30, 67 60( to show a C major chord and then |60 0, 64 0, 67 0( to switch it off (more examples in the help file).
Each of the 4 inlets has a different color to show the note played so you can monitor up to 4 instrument simultaneously.

88keys and 128keys use only canvases to work so they are perfectly compatible with Pd Vanilla, but they are a bit heavy while moving around so please be careful if you're using a low spec machine. They use white.pd and black.pd as building blocks so if you need to build a smaller one you can simply modify the original layout to make a 2 octave keyboard or else, or modify the single key abstraction if you don't like the original colors.

Hope this can be useful for someone, feel free to use and abuse as you wish and please share your own improvement so everyone can enjoy!

PianoKeyboard_shindeibrauns.zip

My guess would be {spigot~}, but if you are in vanilla you have to build a similar abstraction by yourself. This is the one I created for me.

vspigot~.pd

I you want to be a little fancier you can expand the abstraction with the number of routes you want just by replicating [== N] (where N is the number of the route) and [*~ 0] and use numbers (or a radio object) to select the route.

Thanks a lot, this is actually pretty useful!

@CBronisimo The easiest way to do such a thing is to use a metro as a clock signal at the fastest time division you'd like to obtain. Then use a counter, a [mod N] and a [sel 0] to bang every N beats.
This way you can have lots of pseudo-metro functions that depend on just one metro, and they will be in sync every time. Obviously you'll have to reset the counter if you stop and restart the clock metro.
For example, if you want a whole time to beat every 1000 ms, set metro to 1000/32, then use [mod 32] to bang whole time, [mod 16] to bang 1/2, [mod 8] to bang 1/4 and so on up to 1/32 with no mod at all, or [mod 64] to bang twice the time etc... If you plan to go even faster just set the clock metro to 1000/64 or 1000/128 and change [mod N] accordingly. You can even get dotted and odd time signatures this way.

Hope this helps!

pd_extended 0.43.4 includes that, but you have to create an object [import mrpeach] in the patch in order to use its functions.

Are there any autosave options to use in pure data?

I recently found a bug where the program in a certain condition crashes. I'm now aware of what's that condition and I'm pretty able to avoid that while editing a patch, but before that I ended up losing a lots of changes because of the bug and I had to redo everything back from the last save, costing me a lot of time.

If another issue would appear it would be very frustrating.

So how can I automatically save every 2-3 minutes for example?

I'm trying to use touchOSC to control some items in pd_extended using the mrpeach libraries. everything works fine except that when changing page in touchOSC, pure data crashes.

I maybe figured out why since when changing page it sends just "/page" instead of "/page/item value", and since I'm using some cascaded "routeOSC" to address the value to the item I want to change, only the first "routeOSC" sees a value, but then the others receive just a bang.

How can I correct this behaviour? How can I ignore the message when just changing page?