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:
hey @DrJustice first off thanks again or your awesome contributions!
i have a question regarding your moving average object: it defines a couple global (?) constants, FIFO_EXP, FIFO_LEN etc which are derived from the object attributes in local data. when i add several of your objects to a project, axoloti gives me a warning about this on compiling:
/Users/blndr/Documents/axoloti/build/xpatch.cpp:10121:0: warning: "FIFO_EXP" redefined
#define FIFO_EXP 5
^
/Users/blndr/Documents/axoloti/build/xpatch.cpp:9878:0: note: this is the location of the previous definition
#define FIFO_EXP 3
^
/Users/blndr/Documents/axoloti/build/xpatch.cpp:10321:0: warning: "FIFO_EXP" redefined
#define FIFO_EXP 2
^
/Users/blndr/Documents/axoloti/build/xpatch.cpp:10121:0: note: this is the location of the previous definition
#define FIFO_EXP 5
^
/Users/blndr/Documents/axoloti/build/xpatch.cpp:10519:0: warning: "FIFO_EXP" redefined
#define FIFO_EXP 3
^
/Users/blndr/Documents/axoloti/build/xpatch.cpp:10321:0: note: this is the location of the previous definition
#define FIFO_EXP 2
question here i guess is, does this actually define global constants, ie. are they being overwritten on each define and all moving average objects will effectively have the same slew time?
Good catch @weasel79! 
It's a bit of a gotcha... E.g. "#define X 1" defines a C preprocessor macro X wchich gets expanded to a literal "1" before the C file is compiled. So it's not a constant and it's not global. A preprocessor macro is only visible (in scope) within the "compilation unit" it is defined in. Normally the compilation unit consists of a source file and the files it includes (done using the "#include" preprocessor directive).
However, on systems such as the Axoloti, the compilation unit is not be what you get from a normal file by file build. Everything gets stitched together in one single file (axoloti/build/xpatch.c) and so every #define is visible to anything below it in that file. That's why you see all those "redefined" warnings. It still works though. The warnings are given when a preprocessor macro changes value. If a macro is redefined with the exact same value, no warning is given.
I know this and should have followed the best practice for this case, which would be to check for redefinitions. During testing I probably didn't change the length of the FIFO for different instances, so I never saw the warning. And DUH! There's that gotcha!
I've fixed the moving average objects so that you don't get the warnings now. And I need to to that for some other objects too. Just sync your libraries to test the fix. Sorry for the scare and the sloppy practice! 
drj/seq/seq_sync_slave - Syncable sequencer driver
axoloti\axoloti-contrib\objects\drj\seq\seq_sync_slave.axh - Example patch, can also be loaded with object menu "help"
Ready to use
A sequencer controller that can sync to MIDI clock or a clock pulse. In addition to the basics It provides a clock smoothing function, a Swing control and a BPM display. The Control button inputs will also work as overrides when MIDI is the clock source, in addition to being used with a clock pulse.
Example of use (help patch):
Modded the brilliant @DrJustice Multi_wave LFO to behave like the Pigatron/Erica Octasource eurorackmodule with 8 outputs with a 45 degree phase shift each. Hope someone has a use for it.
here is a little video demonstration
https://twitter.com/tekknovator/status/1441986661181804551?s=20
multiwave_lfo_8_phase.axo (8.9 KB)
