Now I seem to have it working with a polyphonic subpatch. But when saving, I always get "1 non-registered params were skipped". And when I load, I always get "1 params less than in current subpatch". So one parameter on the subpatch seems to be 'non-registered' and thus is neither saved nor retrieved.
What does it mean that the parameter is 'non-registered'?
Another question: All the parameters on the subpatch are made available as 'parameter on parent'. Does this mean that these parameters are saved both in the main preset file and in the subpatch preset file? In this case, which overwrites the other?
Sorry for the late replies - summer activities has kept me away from the computer much of the time.
@azaxo : I'm not getting any errors when using a poly subpatch here. If you can post your patch I'll look into it.
@groovy: "1 non-registered params were skipped" probably means you have an integer spinbox parameter somewhere - unfortunately the current Axoloti firmware/software doesn't handle that parameter type correctly so the preset manager can't get to it (hopefully that'll be fixed one day - probably a super simple bug).
The show parameters on parent is only a thing in the patcher AFAIK, so it shouldn't affect the preset manager which only relates to the underlying actual parameters.
As for polyphonic sub patches, I 'haven't tested with those. The preset manager may indeed fail to load parameters for all the voices. I'll look into correcting this, but not right now as I'm rather busy.
@DrJustice Thanks for answering - better late than never 
Since I wrote the questions I have given up Axoloti. This is partly because my Axoloti Core seems to be broken (the communication with the SD card fails, and changing the cards doesn't help); but also because I have concluded that currently Axoloti it isn't the right thing for me. It's simply too hard to get anything useful of of it. I'm sad to say this, because I really like the concept, but I have spent too much time with Axoloti without really getting anywhere. Hopefully, at some point there will be a 'version 2.0' of both hardware and software, and then, perhaps, I'll give it another try.
@Blindsmyth
The syncable delay modules have been updated so that they use the time parameter when they start, instead of 0 time, when in MIDI or external sync mode. When the sync kicks in, it takes control of the time as before.
drj/file/file_size - outputs the number of samples in a named file on the SD card
Ready to use
Reads and outputs the number of 16 bit samples in a named file on the SD card.
The size is read at startup and on a positive pulse on the trig input.
Example usage:
hmm ok.. I'm on a new computer now and it seems I still have lots of modules missing in my /sss/ list and some are still not changed although I know have.. So I think I've kinda messed up my axoloti-github loggin..
So also not sure whether to hit "sync library" button at the moment as the list is incomplete in comparison to my other computer..
Sir, I'm not sure how I can help you. Of course the sources should be on Github, but if you want something like a zip with all your files as replicated here, just say the word.
Regarding your question about the preset manager, sure. Get back to me if/when you have a specific plan there (unless you already have done this - I AM late in replying after all, sorry...)
He thanks for updating the module! I made some custom delay write/read objects that refer to a table now with a friend. works pretty great so far!
@DrJustice These are the patch and the subpatches that I used. While I was setting the patch up again I found that there is actually no issue when I set it to one or two voice polyphony. But when I set it to three the error as I described occurs.
Test Synth Poly4 Wavetable DualTone MIDI v102a.axp (11.7 KB)
CoreWavetableDualToneMIDIV100.axs (19.0 KB)
MidiInKeyboardTracking.axs (5.6 KB)
I get the same result with that patch. With increasing the polyphony and having many parameters, the preset loader blocks for some time, which seems to be the cause. When using the global mode, the parameters are saved for each voice (which is a bit redundant...), but on loading them back it's tricky to make something reasonable and robust to apply them to more than the first voice.
Anyway, I spent quite some time to see what could be done about the situation you're experiencing. In the end I made it so that the loading and saving is performed in a separate thread. Thus the audio thread is no longer blocked on save and load (@jaffasplaffa: that should automatically get rifd of the BLIP, BTW) . That stops the timeout you're seeing from occurring.
While a threaded preset manager is nice to have, it doesn't solve the poly problem. What I found is that using the SubPatchV1 mode seems to cover poly patches, with the drawback of being sensitive to alterations in the patch. Some simple changes to the firmware and/or patch code generator could fix all of that, but I don't think that's going to happen, so at least for now this is as good as it gets.
Please try out the threaded preset manager, and let me know how that goes (sync the libraries to make it available):
drj/patch/preset_manager_t
@DrJustice Thanks for digging into this. I will look into this in the next few days and report back.
@DrJustice I finally found the time to look into this a bit deeper.
I do not get any time out errors anymore. That is what you tried to solve wit the threaded version so that was succesfull.
Something else changed and I do not know if that was your intention. But there are no longer any messages written to the logscreen. In the non threaded version on startup I get three sequence messages. And I get messages when I load or save a preset. I do not get any messages in the threaded version. I do get a message when I tried to load a preset that I did not save.
I also noticed that in Live mode the controls do not update to the value in the preset, while te value in the Core does change . As far as I can rember in the non threaded version these were updated. But I will check this later.
I dit not yet check the other modes. And I did not check the saving of the subpatch settings. But based on what you mentioned before this might not work as expected.
So to be continued....
The messages were taken out, mainly because they take up space, and the when reworking new version I took some steps to save space (it's smaller than the old one). If you would like, I can put back some save and load messages.
As for the differences you're seeing, it could be that since the loading now runs on a separate thread, some update is missing. I'll take look at it. If you can pinpoint the differences you're seeing that would help.
great preset manager!
it seems the program change channel is offset by one. if i want it to listen to pgmchanges on channel 7 i have to set the combo message to 6. EDIT: this is of course a very easy fix, just put a -1 after the attr_channel in the midi code. i did this already locally, but maybe you want to change it upstream as well.
also if pgmchange is enabled, why do i still need a midi/in/pgm object connected to preset and load?
i would have expected this to work with no additional object connected.
thanks for this!
and sorry for posting so much here.
but, when i want a patch with your preset manager as startup patch, the presets that i created before don't work anymore (because they are not in the root directory like the startup patch)
but to edit the parameters i need the axoloti gui and therefore i have to load the patch... and as result presets then get saved into the directory the patcher creates for that patch again. hmm, hard to resolve i guess. maybe you could add a directory option, that can override the default saving location.
Thanks for all your hard work. I love your modules. I'd like to request a lfo/dual_multi_wave with a s-rate sync inlet. This would make an incredible video oscillator. I've experimented a fair amount attempting to sync with the phase reset inlet, which isn't quite tight enough for video.
Basic question about the tap tempo : if I want to multiply / div the clock output with an extra input, I suppose it would be better to modify the live version rather than the attribute one ?
Yes, you'd just have to replace the parameters with inlets. It's so quickly done that I just did it - there's now a version with integer inputs:
