DrJustice contributions

#60

I love your preset manager! Great idea and it works perfect! Thats the right tool when patching work is done. Even Program Change from external sequencer works like a charm! Thank you!
One question:
Cant store the patch including the presets as startup patch on sd-Card? presets always get lost. Is there a workaround?

#61

I'm happy to hear you find it useful - thank you! :slight_smile:

You can use an absolute path in the prefix string. This will let you store and load patches from wherever you want and will make the patch storage location independent of the patch name and whether it's a startup patch (I hope...). A prefix of e.g.:

0:/patches/xyz

Will store and load presets:
0:/patches/xyz000.prs
0:/patches/xyz001.prs
etc.

You would need to create the "patches" directory in the Axoloti File Manager or on your PC/Mac with the SD card mounted.

I haven't tried it on an actual startup patch, but it ought to work - please let me know how it goes if you try this.

#62

Problem solved, found the workaround! I just copied the .prs files directely to the root of the SD-Card.
When my Axoloti is disconnected from PC/MAC, after restart, it automatically loads the Patch named start.bin which has to be located on root..... AND it refers to the .prs-preset files! Great! Maybe you should ask Johannes if it is possible to include .prs files into .bin patchfiles. Thanx again for the good work!

#63

OK, cool that you have it working. The start.bin patch has the root as its home directory then.

With reference to the posting above, about using absolute paths, if you use the name of the patch (i.e. the patch file leaf name) as the name of the directory, the start.bin patch should then access the same presets as if you run the patch live on your PC/Mac.

For a patch file "my_patch.axp", a prefix of "0:/my_patch/xyz" should do the trick. The patch must have been run live first so that the "my_patch" directory is created (or create it manually).

In any case, using a specific directory would remove the clutter of preset files from the root directory and let you manage presets in conveniently in directories.

#64

The Preset Manager has been updated.

Previously there was an issue where the audio could glitch when saving and loading, potentially causing a loud burst of sound. The updated version introduces a new attribute called "volfade" which is used to avoid glitches, and also to control a volume fade for "soft" preset switching.

The "volfade" attribute has four possible values:
- "Immediate" - no fade, may cause a click because the sound is cut off and started immediately
- "Fade 0.02s" - generates a fade out and fade in lasting 0.02, 0.1 or 0.5 seconds each.
- "Fade 0.10s"
- "Fade 0.50s"

The gain fade out/in gain coefficient is available from the "volume" outlet and can be used to control the volume for "soft" preset switching. A new volume control object, drj/audio/stereo_volume, is provided for convenience, but your are free to use other objects if you prefer. When "volfade is set to "Immediate" the "volume" is always at full volume, and thus the volume control object isn't necessary.

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.

See the example patch below for typical use:

test_preset_manager_antiglitch.axp (2.9 KB)

#65

Audio deglitcher and stereo volume controls

drj/audio/deglitcher - audio deglitcher
drj/audio/deglitcher - audio deglitcher with built in volume control
drj/audio/stereo_vol - stereo volume control with external volume input
drj/audio/stereo_vol - stereo volume control with volume knob

status

Ready to use

description

The deglitcher module is for use when you need to prevent audio glitches when invoking a blocking operation.
Typical blocking operations are file saving or loading to and from the SD card, or any other long lasting triggered action which causes audio glitches at the output (the Preset Manager has a built in deglitcher).

The trigger input starts the deglitch operation, which goes as follows:
- the volume is faded out
- the audio output buffer is silenced
- the trigger output pulse is generated, starting the operation which would normally result in glitching audio
- the volume is faded back in

The "volfade" attribute controls a fade out and in before and after the trigger is passed on.
It has four possible values:
- "Immediate" - no fade, may cause a click because the sound is cut off and started immediately
- "Fade 0.02s" - generates a fade out and fade in lasting 0.02, 0.1 or 0.5 seconds each.
- "Fade 0.10s"
- "Fade 0.50s"

Note that when using the Immediate mode for deglitching, the deglitcher module must be place before the output module, as in to the left and/or above it, due to the iteration order.

The stereo volume controls are for general use. The one with a volume control input can be used as a companion module for the deglitcher module and the Preset Manager when using its built in deglitching.

Example use of the deglitcher module, switching between loading two different audio files into a table for continuous playback without audio glitches:

test_deglitch.png879x468 30.2 KB

#66

Hi I'm using your read_sync quite intensly but suddenly it started sounding really glitchy and unpleasant.

I checked on github and realised you had updated it 12 days ago. I suspect that this might somehow altered the sound for me. How could I get back the old version?

EDIT: Replaced it with the old version from my time machine backup. Something doesn't work well with you updated version, maybe you could check that :wink:

#67

I'll check that. I have reinstated the previous one, without clock multiplier. I need to go through those anyway - will get onto that soon.

Edit: the syncable delays now use a better method for smooting - no more glitches.

#68

Moving average

drj/math/mov_avg - moving average, k-rate fractional and integer, and s-rate fractional
drj/math/mov_avg_clk - moving average with clocking, k-rate fractional and integer

status

Ready to use

description

The moving average modules are meant to smooth out and denoise signals.
They have averaging lengths of 2 ,4, 8, 16, 32, 64, 128, or 256 samples at krate or s-rate.
The k-rate fractional and integer ones also come in clocked versions.

The factional ones are designed to accept the full 32 bit value range and will therefore lose precision. The loss depends on the length, and is 1-8 bits for averaging of 2-256 samples. The integer versions have no loss of precision.

#69

Thanks for all of your fantastic work. I've had great fun playing with your sequencer patch (test1 in particular) but it seems to have a couple of bugs. Firstly, the 'set last note' switch doesn't seem to be working. Second, the sequence seems to get out of sync with itself. For example, if I set up a four note sequence, after a while the pitch controller for step 1 stops functioning and step 1 is set by the controller for step 5. Is this a known bug, and can it be fixed?
Thanks

#70

I'm glad you're enjoying it! :slight_smile:

If there's a bug I'll fix it. Do you have an example patch and a set of actions to trigger the bug, that would help in diagnosing it.

#72

Thanks for the preset manager, helped me to finally get how to get the value of any parameter out there to make a preset-morpher :slight_smile:

When I finished this module, could you perhaps take a look and see if there's a way to combine these two modules so your module is able to load a preset into one of the 4/8/more? slots of the morpher which is then able to continuously morph between them?

ps. holy shizzle... this is freaking awesome! morphing the whole freaking drumset all at once, 74 parameters, 64 presets. Using note-value to select a preset and pressure to control the rate of the morph. When you release the note, the knobs just stays at their last position. So you're able to always stay in-between presets, using the presets just as morphing directions to go towards a particular sound character :stuck_out_tongue:

#73

This sound SUPER awesome :slight_smile: Keep us updated!

#74

I have patched my first synthesizers and now I am trying to put in your preset manager and I am experience some issues. Maybe you give me some help in figuring this out.

First the good news. I have a built a mono wavetable synthesizer with a lot of controls. I added your preset manager and it works perfect.

I also have a polyphonic version of the same synth. I created a subpatch for the core of the synthesizer almost all controls are made available in the main patch. In the first try I used the "global" setting and there is no issue when saving the preset. But when I try to load one of the presets the core gets disconnected. The following message is shown in the log.

Ping: WaitSync Timeout, disconnecting now
Disconnect request
java.lang.InterruptedException
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1315)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1296)
at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
at axoloti.USBBulkConnection.DistributeToDisplays(USBBulkConnection.java:1079)
at axoloti.USBBulkConnection.processByte(USBBulkConnection.java:1258)
at axoloti.USBBulkConnection$Receiver.run(USBBulkConnection.java:868)
at java.lang.Thread.run(Thread.java:745)

I figured maybe there is an issue because the same controls are available in the sub patch as in the mainpatch. The preset file is also almost triple the size of the preset file on the mono version so that supports this thought.

So next step was to use the SubPatch mode. All variables I want to save are available on the mainpatch so that could work fine. Now I get the message "96 non registered params were skipped!". The load and save work fine, but ofcourse the controls that were skipped are not updated. Initially I embeded the subpatch as an object. Changing it to a patch/patcher object did not change the behaviour.

Any thoughts on how I could resolve this?

#75

@DrJustice I do not know if you have already seen this message

#76

I am also trying to make it work with a polyphonic subpatch, but I have another problem: when trying to load a preset for a 6-voice polyphonic subpatch, only every 6.th note is played with the new patch, so apparently only one of the six instances actually load the preset.

Tried both savemode=SubPatch and savemode=Global - same result.

Update: now it suddenly works, but I don't see that I have changed anything, Strange...

#77

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'?

#78

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?

#79

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.

#80

@DrJustice Thanks for answering - better late than never :slight_smile:

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.