Hello Folks,
I've got a patch that combines multiple 16 step sequencers to control an SN76477 synth on a chip, via an Arduino. There are separate sequencers for each of the synths parameters: Pitch, LFO Rate, Noise Color, Tuning, Attack & Decay, plus a few logic sequencers for controlling "mix" and pulse wave duty cycle. Each sequence is written to its own array. Things are working quite well so far, and I'd like to take the patch to the next level, which is to be able to recall up to 16 sequences per parameter, For example, the Pitch sequencer would be able to recall up to 16 different sequences. These sequences, along with sequences for the other parameters, could then be strung together to create an arrangement.
The problem is I'm not sure where to start. I've been searching using terms like "save & recall array", but haven't found anything that fits. Anyone have any ideas? To keep things simple, I've attached the abstraction for the Pitch Sequencer. Let me know if I should upload the whole patch, with the many abstractions for this to make sense.

Once I have all of this sorted, I plan on sharing the patch along with the Arduino code, and hopefully a PCB layout for the synth.

Here's a quick video of the patch in action:

16_Purple_Faders.pd

Thanks, Matt

@gsagostinho Many Thanks, Gilberto. This more or less makes sense to me. I don't mind the idea of saving the patch each time, in fact, I think it's a plus.

I'll let you know how it turns out.

Best, Matt

My pleasure. The main idea here is to use the special message [set <something( to create another message containing this [something(, which later can be manipulated, banged, sent somewhere, etc. The advantage is that when saving a patch, this new message will also be saved with all its contents, thus effectively creating a save state. All the rest is just patching. Let me know if you need some help with the patch above then.

Take care,
Gilberto

@gsagostinho Hello Again Gilberto, Your approach to saving presets is working great, but I have 2 questions that you may be able to answer.

Is there a way to update the sliders when a new preset is loaded? Everything I've tried ends up creating a loop and freezes the patch. I thought I saw an object somewhere that makes a hot inlet cold (or perhaps it was a dream). Anyway, this would allow me to send the updates to the sliders without that data being sent to the slider's outputs.

The second thing is, is there a way to save all of the abstractions from the main patch, instead of opening them one by one and saving them individually? I'm using 9 abstractions, so it's a bit of work to save (and remember to save) each one.

Best, Matt

Hi Matt,

Yes, there is. You are getting these crashes and freezes due to a stack overflow: the sliders are feeding the messages which are feeding the sliders back again, and so on, in an eternal loop.

The solution is to add a messsage [set $1( before the sliders. Basically, if you send a number to a slider, the slider will immediately output its new value, which causes the overflow. Now if you send it a message such as [set 127(, the slider will move to that position but it will NOT output this new value immediately (it works similarly to the rightmost inlet of a [f], for instance).

Let me know if this solves your problem.

As for the second problem, I do not understand exactly what you are looking for. What do you mean by "saving all the abstractions from the main patch?"

Take care,
Gilberto

@gsagostinho Hi Gilberto,

Yes, I thought that I was getting a stack overflow. I will implement what you've suggested.

To better explain the second issue, I included a patch in my original post called 16_Purple_Faders, which is only one of several subpatches (abstractions?) that are called into the main patch. Although I can write to the patterns from the main patch, I am unable to save the contents of the subpatches unless I open and save each one individually. So my question is is there a way via a script, object or additional subpatch that would allow me to save all of the subpatches being used by the main patch?

I've included a simple example that will hopefully clarify things. PurpleAndOrangeFaders.zip

Thanks, Matt

Hi Matt,

I believe I understand your problem now. But to be clear, in your case you are using abstractions, not subpatches. Abstractions is when you save a new .pd file, such as myAbstraction.pd and then create a new object in Pd via [myAbstraction]. A subpatch is when you create an object [pd mySubpatch] and then add some algorithm to it. For you, I would recommend using the latter one, because a subpatch is contained in the code of a patch, and so you won't be prompted to save several times.

But if you insist in using abstractions, you can force them to save themselves algorithmically when a modification happens. Let's say you have an abstraction called myAbstraction.pd once again. If you bang the message in the top of the algorithm below, it will automatically save that abstraction:

[menusave(
|
[s pd-myAbstraction.pd]

Remember to change s pd-myAbstraction.pd for your abstraction's name, but keep the s pd- in the beginning. So you can simply use a [trigger bang] to activate the message [menusave( immediately after a message box is modified with a new preset. Does it make sense to you?

I hope this hepls, take care,
Gilberto

@gsagostinho Once again Gilberto, Thank You!!! I see now that the distinction between a subpatch and an abstraction is an important one. I'm taking your advice and converting the abstractions to subpatches, so that all of the data gets saved with the main page.

This is my first serious Pd project, and so your guidance has been a tremendous help.

Best, Matt

Hi Matt, I am glad it works. If you have any other questions, just post it in this forum. Good luck with your project! Gilberto

Hi Gilberto,

I noticed one flaw in the original patch you sent me that caused the current preset to be overwritten by the previous preset as soon as you touched a fader. I've figured out a fix, but was wondering if you see a simpler or more elegant approach.

Thanks, Matt

save_v2.pd

@mattm Hi Matt,

I don't know if this is a more elegant solution or not, but I think I prefer it like this:

save_v3.pd

As you can see, now you simply hit a button to save to a state and hit another button to load a state. It seems to be working well now.

Please let me know if you need help understanding the patch, ok?

Take care,
Gilberto