I see one Lua script example of how to automate loading a preset.
I want my program to send a message to an individual plugin to save the current preset. I cannot find anything in scripting, OSC, or MIDI control for this; only for browsing or loading presets.
I see hundreds of scripting commands and actions listed in the docs. What command could tell Ardour to save the current preset?
Many plugins have begun to implement the Scala tuning file format, .scl; but all of them implement it only by mouseclick. Fine, then, my program can rewrite the same .scl file over and over as tuning changes. But none of these plugins ever even reload the same file. This functionality is provided to be used ONLY by end-users, click by click, never by programs. In most cases, they assume you want to “play around” with a couple of tunings. Well, I discovered that if I manually create a preset for whichever plugin, load a .scl file, change the already loaded .scl file on disk, and finally save the current state over the preset in Ardour, the plugin does indeed reload the .scl file (I tried with Amsynth, and with Plogue Sforzando on Windows, and I hope it applies to others). But this is one action that, as far as I can find out, Ardour does not allow to be automated: to save over the current preset. In fact, with 5.12.0 on Debian testing, it takes at least a minute of 106% CPU usage for Ardour to recover from saving the preset by mouse click, but it does work.
OK, I guess I got confused. That is good news, as it shouldn’t be dependent on plugins, though whether saving a preset triggers any given plugin to reload its tuning files I will have to find out by trial and error.
My original plan, to tell the plugin to reload directly, appears to be done by plugins; i.e., loading an ASCII file interactively. I haven’t been able to find any external parameter for this, and so it’s workarounds. It works in Reaper, with a command to save and immediately recall the current snapshot. If the save command can be accessed, it should work in Ardour. I see loading the preset as a Lua script, but that would interfere with the user’s other automations.
But it does move!
With Amsynth and a .scl file.
If someone decides this is a bug and fixes it, I’ll just add the step of reloading right after saving.
The plugin’s internal state apparently includes the path to the scl file, though it doesn’t make that parameter available to the host. I suppose it saves its current tuning, but then overwrites it because the file pointed to by that path has changed on disk.
This is a workaround specifically because most audio software offers endless control of timbre and almost no control of pitch.
If this description is correct, that’s clearly a bug in Amsynth.
“almost no control of pitch” … welcome the world that MIDI created. Lots of people have spent the last 4 decades complaining about what MIDI did to flatten, quantize and overly-simplify notions of pitch in electronic music creation. Be a fixer, don’t just join the chorus of complaint!
OK, I wouldn’t come to this forum just to complain about that. I’d just complain on Facebook…
I’m out here looking for ways to communicate frequency information from my microtonal sequencer (AFAIK the only piano-roll style sequencer that doesn’t require the use of preselected scales) to other programs. So far, this involves trying to trick them, and/or proposing changes to other programmers. That’s why I asked my original question of how to access this “save preset” function from a script.
GIMP makes it simple to select from at least 16 million colors while creating, not before. I’m in the process of trying to offer this to musicians.
Continuously variable pitch in the context of electronic music has most often been associated with analog synthesis where a control voltage (CV) gets interpreted with various levels of resolution by the oscillators (and their control mechanisms).
If you use MIDI, there’s no true analog of this, though of course the MIDI Tuning Standard does allow you to remap each MIDI note to a completely arbitrary frequency. But the fact that MIDI note messages are quantized, unlike CV, fundamentally changes the landscape.
OSC is no help here, in general, because there is no standard for OSC messages. There is, for example, no single message you can send to an OSC receiver that will make it start making a sound, let a lone a specific pitch.
You might find it more appropriate to construct your engine as a rack module for VCV Rack, where it can use CV to its (and your) heart(s) content. If you continue to require it to be driven by MIDI-style discrete messaging, it will likely always be a source of frustration.
Thanks for the suggestion. I personally like Csound and Pure Data for my own compositions. My program already gave me the tuning freedom I wanted years ago, but now I’m specifically trying to add MIDI because it’s been requested.
I’ve figured out how to do it without problems in Reaper. It’s a complete workaround, but the control I have with scripting - and some free extensions - provides everything I need.
You suggest to change files under the hood while a DAW plays in real-time and then force a plugin to re-read a file, hoping it’ll happen click-free and reliably at a certain point in time… – That sounds like an awful hack to me.
How about during faster-than realtime export or even just a locate while rolling?
Do you have any control over the plugins? LV2 allows to automate loading external files (worker thread), also LV2 plugin-state and presets can be partial, changing select values only.
Certainly, you can use various mechanisms to change how your plugin interprets MIDI messages, and thus get whatever tuning you want. Technically the MIDI Tuning Standard allows the same thing, and would be a more “standard” way to do this, although very few synthesis engines support this anyway. And yes, the most obvious mechanism is very similar to a “preset” where the main aspect of the “preset” is the mapping from a MIDI message to a given pitch.
But as Robin notes, there are better ways to do this, especially if you use the LV2 plugin format.
Is that also the explanation why sound fonts that are selected in the a-FluidSynth plugin never get into the ‘recently used files’ list?
It is such a nuisance to have to traverse the file system each time I need to configure this plugin.
The are added to the file-selector’s recent list just fine. That is a feature of the gtk file-dialog, unrelated to the plugin-state. I just checked it works here. However, that list is not very long and if you also use other gtk apps the selected .sf2 won’t be “recent” enough anymore between sessions.
You could create presets of that plugin. Those do include the soundfont.
I have not played any of the virtual-CV software implemented instruments. Can those route CV to an Ardour track so that a performance on some kind of controller which results in virtual-CV output can be recorded to a pseudo-audio like track, and that track routed back out to a CV input on a virtual synth so that you can play back the same performance, but make changes to the patch or other sound aspects?
I guess the same question could apply to a traditional control voltage type synth, but that would require an unusual interface with DC accurate response, more like an ALSA interfaced instrumentation device than a traditional audio interface (instrumentation in the sense of electrical laboratory equipment, not musical instruments).
I’m actually not writing any plugins. It’s a standalone sequencer. It has output through Csound orc, OSC, or loaded soundfonts, and I’ve been mulling over how to make it compatible with more sound sources for years. It will likely follow MIDI clock messages and SPP from a DAW instead of its current Csound engine. (Csound only allows ONE MIDI output device, and they have told me for many years that this is unlikely to change.)
As you point out, the continuous pitch thing is really not a limitation of MIDI, since MTS, but of the software that doesn’t implement it. A few dozen now support Scala scale files. AFAIK that’s more than support virtual CV input.
I can perform the change of snapshot/tuning file in Reaper by duplicating tracks. My program can know exactly which tracks, ports and channels are used, then duplicate the tracks at the start of playback and assign unused MIDI channels to them. So one track reloads the Scala file while the other takes over playing, and at the end of playback the duplicates disappear.
Sloppy, but it does work. Of course there are other ways to realize continuous pitch control, but this is one way.
Yes, that is what I meant, record a continuous control signal so you can play it back later, just as you can today with a MIDI sequencer. Kind of a control voltage recorder instead of a MIDI note recorder.
That way you can record the pitch and timing you want performed, and work on the details of the patch later in case you want to change the sound (or manually perform parameter changes that you don’t have enough hands to perform while also controlling the pitch, etc.).
Yes, off topic of saving presets, I was getting this mixed with the other topic of ways to have non-standard pitch values, like a sequencer not limited to MIDI note values.
Referring to this part of an earlier reply: