Preset Manager with axocontrol

#1

I'm pretty fresh to the axoloti .. so now I started to put together a simple project with the axocontrol using 7 presets and have the 3 LED display them for me.

I have one question and one problem.
first the problem:
there is an audio Glitch when executing a preset load/save, is there a work around ?
now the question:
I'd love to glide from one preset to the next, with a adjustable lag time does anybody have an idea how to solve that ?

oh yes and the patch is not yet finished...

AXOCONTROLtest.axp (17.2 KB)

thanks Nicholas

#2

nobody has anything to say ?
:disappointed_relieved:

#3

sorry the present manager is a community library object from @DrJustice, I therefore left this post for his input.

however, on reflection its a more general point , which is changing presets could cause audio glitch.
if you are changing parameters that if altered instantly might result in a glitch (or even just an undesirable sound)

in particular you would have to be careful, since the order that parameters are changed is not fixed.

there is no mechanism to glide from one value to another, but its a good idea ...

however there are a few possible solutions.
- rather than saving a preset on a dial in an object rather feed use an inlet, which is fed with a dial , thru a smooth object (or similar)
- take care with what you put in the preset, not all parameters have to be saved/recalled.
- consider some kind of delayed trigger to temp mute parts of the patch during a switch

I know these are all a bit vague, but Id have to really experiment with this to demonstrate these ideas... and I (personally) dont have time at the moment....
of course these are 'workarounds' , its true a glide could be a nice feature for the future.

@johannes do you have any other ideas for workarounds etc? or generally thoughts?

#4

cool, thats already helpful

#5

@Grandprixdamour one point, i forgot to say!

In the above Ive made the assumption that the glitch is caused by preset values changing rather than the preset manager.

this is worth testing, as its a big assumption!

do you get the same glitches is you change presets with the preset buttons in the axoloti UI?
(the numbers next to RECALL at the top of the screen)

if you do, its the underlying preset changes

if you do NOT then its an implementation issue with the preset manger, so would need to be addressed there.
(sorry, I dont know the details of the preset manager, because as i said it a community object)

#6

@Grandprixdamour ok, so I took a quick look at the preset manager code.

NOTE: this is just a quick glance, so i could be wrong.

it appears to be loading data from the SD card in the audio thread (k-rate) , we always recommend this is not done, doing I/O in the audio thread is likely to cause audio glitches. IO should be done in a separate thread.
also the code just restores parameters in the order they are created in the patch, so this could potentially cause issues.

(don't get me wrong, creating a preset manager is not trivial, and avoid glitches even more so!)

Id advise you find a mechanism within your patch to mute outputs before the load is initiated, and reactivates a short while after , once the load has completed.
It may be the preset manager has mechanisms to help you do this, but again i don't know it well enough to comment.

#7

Hi Tbear

Right now I have to work on a raw player for an installation, I can check the preset problems another day.

#8

Yes, there will be a small audio glitch, if the patch is sounding, due to the Preset Manager (PM hereafter) blocking the synthesis thread while saving and loading, and also when parameters change drastically of course. I did consider forking out the save/load code to a separate thread, but that might have its other synchronization issues, so I thought the safest thing is to block the synthesis thread for a moment.

Regarding resilience against moving objects positions in a patch, the PM has a save mode ("SubPatch") which uses named parameters which is safe in that regard. The downside is the non-appearence of the integer spinbox parameters (ParameterInt32Box) in the parameter table. This bugette has been mentioned several times when discussing the PM, and I still hope it will be addressed in an update (should I file an issue in GIT?). There is also the previously discussed request for a table with pointers to each sub patch root, so that a single PM module could do a global named parameter save.

For the audio glitch issue, I could introduce a new outlet on the PM, with a gain value that would be quickly ramped down and up before and after the actual load/save operation. Connecting that output to a gain module (or a new output module with a gain input) would then hopefully eliminate any 'dangerous' audio glitches.

Edit: If anybody wants such a fading gain coefficient, as described above, just say the word and I'll make it.

I'd also like to deprecate the SubPatchV1 mode to reduce the code space.

You can read about the latest update to the PM here.

#9

thanks @DrJustice

do you know if its limited to this parameter type? - Ive vague memory when I was browsing the parameter table on the push, there might be others too.
sure , you can raise an issue on git, always good so we dont forget - we will be revisiting parameters for the next major release, at which time I will check all parameters are available.
(the next dev cycle, after 1.0.12, is going to be a big one, so we can get on with things we have been aching to do for a while :wink: )

#10

Not sure, no - but its the only one I've personally found missing. There are many parameter types I've not verified yet. Hopefully any others will be caught when you go through them for that update. I'll see about filing it on GIT :+1:

#11

Calling file I/O functions in audio processing functions will unavoidably cause a buffer underrun. I suggest calling codec_clearbuffer() before calling the first file I/O function in such case. That will not avoid an underrun, but it will silence the underrun.

I'm hesitant to make changes in the parameter system before arriving at substantially refactoring this in the near future.

#12

Thanks - will insert a codec_clearbuffer() as a first measure, then possibly the fade in/out functionality to avoid clicks. For now I remain reluctant to start a new thread because of potential synchronization issues (like a new patch being loaded, or multiple PMs being used etc.).

I'm hoping that the inclusion of the various parameter types is data driven. maybe with an attribute for the appearance in the parameter table which could be quick to correct? Anyway, I'm looking forward to a parameter refactoring since I have a "special interest" there :slight_smile:

#13

You have probably read my previous posts in this thread. I have adopted the method proposed by Johannes, to silence the output. It may still cause a click as it goes from some sound to silence and vice versa, but there should be no bad sample data in the output buffer to cause untoward noise bursts. This will be active for the PM once I sync the change to the repository (I'll drop a message here when that happens). Then there's the fade out/in method which I may implement next if there's demand.

There are two issues with this. One is that not all parameters can glide smoothly, e.g. switches, and may cause audio spikes/noise as abrupt changes happens. That could be said to be the patch/preset author's responsibility though (only load patches that has no abrupt changes, like potentially noisy switches changing, relative to the current one). The second is that code space is precious and the PM already consumes a bit of that - may not be a biggie, but worth keeping in mind as features are added. I could potentially make an extended version of the PM with extra features for those who want them, but I'm not too keen on diverging the module development like that. We'll see.

Also keep in mind that the PM is to be considered experimental or in-development, until some of the parameter code refactoring that thetechnobear and Johannes have mentioned (mainly to be sure that no parameter types are missing when using the SubPatch, i.e. named parameters, save mode). However, is users find that the PM works for them, there's no reason not to use it - I intend to follow it up so that transition to newer versions are as painless as possible.

Edit: The PM is now updated with the "silence while saving and loading"-method. You can sync the libraries and test if you want.

#14

@DrJustice

Over here the audio glitch when changing preset is also noticed. The glitch really bugs me a lot. So I went back to Axolotis own preset system. If you change preset when being live, you get the glitch. This can be pretty devastating.

But all this code refactoring etc. sounds really interesting. Cant wait to see what come up in the future :slight_smile:

#15

The glitch workaround is of course to make sure there is no sound at the moment of saving or loading presets. Not satisfactory, but you do get the luxury of totall recall without glitches if you do. The built in preset system (which I never could get to work - it needs some concise docs) can't replace the Preset Manager - I still consider the latter an essential part of any synthesizer.

I've toyed with the idea of preloading all saved presets into RAM, so that the loading of a saved preset will be near instantaneous, just like the built in presets. However, that starts to feel like doing too much of a fudge code wise and resource wise...

I don't know how far the refactoring of parameters will go, that is, whether it'll introduce a total recall, or "conventional", preset system.

Edit: the info below is updated to reflect the latest version of the PM.

Right, let's try to make things better then. I've synced up a new version of the Preset Manager. It introduces a new attribute called "volfade" with four values:

"Immediate" - switches patches immediately, may cause a click, but noise/tone burst
"Fade 0.02s" - generates a fade out and fade in lasting 0.5, 0.1 or 0.02 seconds each.
"Fade 0.10s"
"Fade 0.50s"

Note that when using the Immediate mode for deglitching, the Preset Manager must be place before the output module, as in to the left and/or above it, due to the iteration order.
Below is a test patch (picture and axo file). Please test it and let me know how it goes.

test_preset_manager_antiglitch.axp (2.9 KB)

#16

Wow! Nice @DrJustice

Thanks, will try it out :wink:

Axolotis own preset system is good, but it has got its limitations. The benefits is no glitch sound. But downside is that it take a bunch of ram and it is a bit complicated making presets. When I got a finsihed patch that I am happy with, there are usually not much ram left for presets.

And that is where your system comes in. You can make lots of presets, and it is much easier creating the presets...... but it unfortunatly glitches.

Anyway, I will test the new version you have made... I would much rather have an audio drop out than a bliiiib, so IMO it is a step in right direction. Look forward to try it out :slight_smile:

The blib can be very dominating on a large PA system. Maybe it wouldnt matter sitting at home, but in a situation where everything is LOUD, it will play a role.

Does the Preset manager use a table for the storing/loading? Is that where the bliib comes from?

A while ago I got a new sd-card that was atleast 2 times faster than the old one I had. And that actually shortened the blib a bit, when loading tables. I havent tried using the PM since I got new sd-card.. Maybe this will make the blib less noticable too....

About the code refactoring, yes maybe it wont matter that much. But i would sure like to be able to assing the integer spinboxes to midi cc number. That is one of the things I'd love to see implemented, that was one of the reasons I mentioned the refactor of parameters. I think this would also make them included in your PM system, I guess.

#17

Ok all ready tested it...

This is super! I tested both volume and silence mode. Both works pretty great. Only a very short click when switching preset in silence mode.

This means that in a live situation you would be able to change preset without having to mute the Axoloti on the mixer first. Much more safe and much more useful!

THANKS again!

#18

Thanks for testing :slight_smile:

The glitch "bleb" sound is (was - I'll remove the "None" option!) due to the current buffer being played repeatedly until the save/load is finished and new data becomes available AFAIK, so the 32 sample buffer becomes a high frequency periodic noise/tone.

The fade time is currently 1/2 sec for each of out and in, so 1 sec in total. Perhaps I should add a fast option, so we get "Fast fade" and "Slow fade" instead of "Volume" (better naming too). Say, 1/10 sec, or maybe even faster, just enough to avoid a click, and the current 1/2 sec - would that be useful?

#19

ahh ok, now I get it!

Actually I was thinking about the fade time for the vol too. That would be great to be able to set a bit faster.

I just tested automating preset change with a square lfo and a rand/uni object. There are a few clicks, but much better than before. But for a regular synth where you just want some nice presets to choose from, not automate, it is really great!

But maybe the fade time would also help on the automation clicks.

#20

thank you very much !

I don't have my axolotl handy but it sounds very useful.
This makes the preset manager useable on stage, great !