Feature Request: Faders programmable through the Mod inputs

[maunatanmaya]

Faders Module:

Would it be possible to add the capability to program Faders patterns through the Mod inputs?

Faders can be programmed with a combination of CV-MAP and Moots modules, but it would be very handy to allow the Mod port on a Fader block to be switched into a programing mode (possibly by a small button beside the port).

In programming mode it would also be useful if the polyphony of the block for each pattern could be set by the polyphony count of the cable going into the Mod input.

[docb]

this may make sense if you would like to have both, modulation and setting the fader base value from extern.
when i only want to set fader values i set the mod cv knob to 1 and connect an arbitrary source e.g. a PLC.
If you set the mod cv to 1, you can also take a M16 module put the output to into the mod.
Now you can connect any mono source to an arbitrary fader value. When i have two sources e.g. an lfo and a constant bias
i use simply the OFS module in forehand. there you have all modulation possibilities.

[maunatanmaya]

I apologize for being unclear.

Here is a revised request for enhancements to the Faders module:

Mod and Out ports for each block work the same as in the original Faders module

Each block has two additional input ports:

• Prg - single channel or polyphonic CV
• Enable - single channel or polyphonic gate

Each block has two toggle buttons

• Active (orange button, functions as an indicator light if Enable port is patched)
• Match Chan. Count (blue button)

Module behavior for a given block

Prg input is unpatched:

• Block behaves normally

Prg input is patched and Active button off :

• Block behaves normally

Active button on and Prg input is patched, Enable port is unpatched, Match Chan. Count button is off:

• All fader values are set to the values of the corresponding channels of the Prg input
• fader values set by the Prg input to that block are saved to the current pattern
• fader sliders in the block set by the Prg input cannot be manually adjusted
  -- fader sliders in the block not set by the Prg input can be manually adjusted

Active button on and input Prg is patched, Enable port is unpatched, Match Chan. Count button is on:

• All fader values are set to the values of the corresponding channels of the Prg input
• fader values set by the Prg input to that block are saved to the current pattern
• fader sliders in the block set by the Prg input cannot be manually adjusted
  -- fader sliders in the block not set by the Prg input can be manually adjusted
• Polyphony channels of the block for the current pattern are set to the polyphony count of the Prg input

Prg and Enable inputs patched, Match Chan. Count button is off:

• Active button functions as an indicator light instead of a toggle button
• If Enable input is monophonic, all channels of Prg input set the values of the corresponding channels in the block
• If Enable input is polyphonic, a high gate in an Enable input channel will result in the the corresponding channel of the Prg input being set in the fader block
• fader values set by the Prg and Enable inputs to that block are saved to the current pattern
• fader sliders in the block set by the Prg input cannot be manually adjusted
  -- fader sliders in the block not set by the Prg input can be manually adjusted

Prg and Enable inputs patched, Match Chan. Count button is on:

• Active button functions as an indicator light instead of a toggle button
• If Enable input is monophonic, all channels of Prg input set the values of the corresponding channels in the block
• If Enable input is polyphonic, a high gate in an Enable input channel will result in the the corresponding channel of the Prg input being set in the fader block
• fader values set by the Prg and Enable inputs to that block are saved to the current pattern
• fader sliders in the block set by the Prg input cannot be manually adjusted
  -- fader sliders in the block not set by the Prg input can be manually adjusted
• Polyphony channels of the block for the current pattern are set to the polyphony count of the Prg input

I understand that adding these features might take some work and I am happy to support development.

[docb]

• so far the only purpose of this module was to provide (a lot of) user defined values. all other stuff can be done outside the module e.g. when i set a value from outside, then this value exists already in the patch. could you please for a better understanding outline what you exactly want to achieve with this functionality.
• TBD: it may be better to make a dedicated module for this or making an expander.
• TBD: what should happen when the bank is changed when the Prg input is active.

[maunatanmaya]

so far the only purpose of this module was to provide (a lot of) user defined values. all other stuff can be done outside the module e.g. when i set a value from outside, then this value exists already in the patch. could you please for a better understanding outline what you exactly want to achieve with this functionality.

The main points are:

• Faders provides a lot of user-defined values
• It is CV addressed
• Can be controlled with ACC, phasors, sequencers, other Faders instances, alone or in combination
• Faders presets can be changed or sequenced with Preset, which is also CV addressed

Importance of programmability:

• Recording becomes possible
• Batch programming becomes possible
• One can still view and edit recorded values within the module

Recording via:

• MIDI input (hardware and ReaLearn/REAPER)
• OSC input (TouchOSC, ReaLearn/REAPER, other)
• Sequencer subpatches within Rack
• CSV (with 02NAGOL)
  --this one is important, LibreOffice Calc can make things a lot faster and easier when setting up configurations
• DAW input (ReaLearn, Midi/OSC)
• ReaLearn (recording and control as a part of the REAPER/ReaLearn/Rack ecosystem)
• as part of Generative sequencing subpatches

TBD: it may be better to make a dedicated module for this or making an expander.

A dedicated module would be needed, as an expander would prevent the use of Preset

Additional feature request:

• four 16 channel blocks instead of three 16 channel blocks

TBD: what should happen when the bank is changed when the Prg input is active.

If a pattern bank is changed when the Prg input is active, the new pattern bank will take on the current value of the corresponding channels in the Prg input. Other channels in the block are left unchanged
If any Enable gates are high, only the corresponding channels of the Prg input will will change the corresponding values in the Block, others will be unchanged.

Additional feature request:
An additional single-channel trigger input port which, upon receiving a trigger:

• silently overwrites the currently loaded preset

or

• if the module is initialized and a destination file is selected in the module menu with an option to auto-enumerate saves - similar to LOGAN and LOGAN20 - the module will auto-save/enumerate presets upon receiving each trigger.

Thank you for considering an enhanced Faders module, it will make a big difference in my work, and I am glad to generously support development of these features.

[maunatanmaya]

...another option might be to create a narrow-format module with:

• only one block per module
• no Mod input
• sliders and slider display active only when Lock pattern is on

Might be a lot easier to accomplish and still do the job.
...and much faster pattern switching rates might be attainable.

[maunatanmaya]

I realized a much simpler solution - and no need to create a new Faders module!

Add a trigger port to the Preset module which upon receiving a trigger:

• silently overwrites (and saves) the currently loaded preset

or

• if the module is initialized and a destination file is selected in the module menu with an option to auto-enumerate saves - similar to LOGAN and LOGAN20 - the module will auto-save/enumerate presets upon receiving each trigger.

That way, almost any module can be programmed with a combination of CV-Map, ACC, and Preset

[docb]

ok this seems to be doable.

but i still like the idea of the stripped down faders module, programmable e.g. via midi keyboard.

[maunatanmaya]

It would be great if you would be willing to both create a FadersOne and add save-trigger functionality to Preset!

[docb]

do you really want to messup the preset dir with
entries of the form
...../preset_1.vcvm
...../preset_2.vcvm
...../preset_3.vcvm
...
...../preset_15632.vcvm ?

[docb]

Additional note: the rack module itself does not now any presets. presets are only applied (and forgot).
i.e. after applying a preset there is no information in the module which preset is actually loaded.
so only the preset module knows the current preset but only when a preset was applied before (using CV or buttons)
So loading a preset inside the module via the menu, will have no effect when trying to overwrite it.

[maunatanmaya]

do you really want to messup the preset dir with
entries of the form
...../preset_1.vcvm
...../preset_2.vcvm
...../preset_3.vcvm
...
...../preset_15632.vcvm ?

No need to mess-up anything.
It would work similar to LOGAN and LOGAN20

For auto-enumerate saving of presets:

• Navigate to an appropriate sub-directory within the user preset directory of the module
  --(the directory can be created beforehand in the OS's File Explorer)
• Choose destination file name
• In the Preset module menu, check "Auto-enumerate saves"

...that way, auto-enumerated presets can stay organized in the chosen sub-directory and be reorganized with various utilities.

Additional note: the rack module itself does not now any presets. presets are only applied (and forgot).
i.e. after applying a preset there is no information in the module which preset is actually loaded.
so only the preset module knows the current preset but only when a preset was applied before (using CV or buttons)
So loading a preset inside the module via the menu, will have no effect when trying to overwrite it.

I'm a little unclear on what you mean.
Are you saying that once the Preset module loads a preset into an adjacent module, it would be unable to re-save that modules's preset?

[maunatanmaya]

...Thinking about what you were saying regarding Preset:

I think it would be better to focus on FadersOne instead of Preset, as it will do the job and save on having to modify Preset, which works very well in it's current state.

[docb]

here is the current status for testing:
https://github.com/docb/dbRackModules/releases/tag/v2.6.0-dev
https://github.com/docb/dbRackSequencer/releases/tag/v2.6.4-dev1

[maunatanmaya]

Preset is working great.
Thank you for adding this much needed feature!

Osc22 and FadersOne are not showing up in the Rack module selector window.
However, Osc22.svg and FadersOne.svg do show up in ../plugins-win-x64/dbRackModules/res.

Tried removing/reinstaling dbRackModules and then installing the update - still the same problem.
Also tried rebooting Win 11 - still the same.

Searched the Rack log.txt file for occurrences of "FadersOne" and "Osc22" - none found.

Please advise

[docb]

I tried it on Win 11 (download and put in plugins-win-64) and it worked. So i need the logfile.