# Boot drive configuration file ideas **URL:** \ **Category:** Feature Wish List\ **Created:** [1 August 2024 20:32 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799 "2024-08-01T20:32:08Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![sntr](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.udo-audio.com/sntr/32/884_2.png) [@sntr](https://forum.udo-audio.com/u/sntr)\ **Post date:** [1 August 2024 20:32 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/1 "2024-08-01T20:32:08Z")
Hello, Absolutely enthralled with S6. I’ve come to appreciate the exclusion of a screen. Using my hands and ears rather than eyes is refreshing with a new synthesizer. No menu-diving! ❤ However, the lack of screen also creates some limitations for the firmware that can be implemented while keeping the UI sensible. Worst-case scenario users have to recall increasing amount of shift-functions that are not marked on the panel as there’s no screen to reflect new menu items etc. There’s already been some discussion about possibility for a configuration file in the boot drive to alter / modify some deeper settings or even architectural aspects of the synthesizers. This type of configuration file in the Boot drive would give UDO additional “UI room” for features. I thought that this idea deserves it’s own topic for discussion. I’ve had lots of experiences with config files on the modular world. They are a simple way to give users a handle on some aspects that they would like to change / address but that are not pivotal to the central operation of the synthesizer. Some ideas that come to mind: **#1:Cross-mod type** : “Exponential FM” (default), “Linear FM”, “Linear through-zero FM”, “Oscillator feedback”, “Binary combine” _Explanation: Exponential FM is pretty intense most of the time. The possibility to introduce linear, LTZFM or even single-oscillator feedback (will introduce pitch instability but it’s fun!) could open up cross mod for more uses. Binary combine would use the cross mod fader to switch between AND / OR / XOR etc. binary logic operators between the values of DDS1 and DDS2 this is a classic for achieving brutal digital artifacts and would fit the Super 6 aesthetic well IMO._ **#2: Switch Bend+ / Bend-** modulators to other sources such **note number** (discussed in some other topic already), **LFO1** (would be great but I don’t think it’s happening), **ENV2** or even **Bend±** (combination of the two) _Explanation: Bend+ / Bend- already has the possibility via panel controls to affect two of the most high-value modulation targets in DDS (each of them or separately) and the Filter, I think it’s redundant to have separate Bend + / Bend - as mod sources._ **#3:** Settings for **envelope responses** : Linear, Logarithmic, Exponential. Preferably this could be configured per ENV1/2 stage, so we could have exponential attack with logarithmic release. 😅 _Explanation: Somewhat exponential response can already be achieved with modulating the envelopes with ENV1 already, but it would be nice to have per stage response settings and more creative options._ **#4** : Settings for **DDS2 Tune** control to **frequency-ratios of DDS1**. I kind of love the Tune control already, but there could be a fun setting to force DDS2 to a frequency that is multiplied / divided ratio to DDS1 frequency. This would be great fun implemented together with #1. This might be not-feasible because of the way DDS2 resets on key press, but it’s an idea! **#5: Delay lo-fi mode!** 🔥 Increases the delay times by lowering the sample rate of the stored audio. There could be several settings “clean (Default 96kHz), medium lofi (~ 24kHz), lofi (12kHz), total destruction (6kHz)” _Explanation: Since the delay time is mostly limited by menory capacity, lowering the fidelity of the stored audio increases the possible time and gives people option to have a bit more characterful effect. It’s a win-win! Novation implemented this in the last big updates on Peak/Summit and I love the option._ Do you have any ideas for Boot drive config file? Let’s hear them! ---
**Author:** ![udo-audio](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.udo-audio.com/udo-audio/32/8_2.png) [@udo-audio](https://forum.udo-audio.com/u/udo-audio)\ **Post date:** [1 August 2024 21:06 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/2 "2024-08-01T21:06:15Z")
@sntr thanks for sharing these insights they are very helpful to know what would be useful! ---
**Author:** ![GregVDS](https://avatars.discourse-cdn.com/v4/letter/g/90db22/32.png) [@GregVDS](https://forum.udo-audio.com/u/GregVDS)\ **Post date:** [3 January 2025 16:09 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/3 "2025-01-03T16:09:19Z")
Funny, I was imagining exactly that, for the user to be able to set some deep behaviours of the synth. I thought about these to be defined in the config file: - When the settings are different than the physical control, one could choose between pass-through or direct snap to value - voices allocation; I saw here that there was different way of doing it and that some preferred the og way, other were accustomed to other methodologies, and I think I heard George in some YT video explaining he took a fair amount of time designing the voice allocation strategy, so this could also be choosen via the config file. - Chorus types / delay types maybe? - Envelopes ramps types I still do not have my SG, but am sure using it will bring more ideas :-). @udo-audio , what do you think about this? would it be feasible? I mean this requires the synth to read an ascii file at boot, and choose according to the set key-values between several algorithms, that, hence, need all to be present in the compiled firmware… Do we have enough room for this in the firmware? ---
**Author:** ![GregVDS](https://avatars.discourse-cdn.com/v4/letter/g/90db22/32.png) [@GregVDS](https://forum.udo-audio.com/u/GregVDS)\ **Post date:** [7 January 2025 07:06 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/4 "2025-01-07T07:06:30Z")
This [topic](https://forum.udo-audio.com/t/adjust-release-curve/3071/7) has some other ideas also 🙂 ---
**Author:** ![udo-audio](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.udo-audio.com/udo-audio/32/8_2.png) [@udo-audio](https://forum.udo-audio.com/u/udo-audio)\ **Post date:** [8 January 2025 19:17 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/5 "2025-01-08T19:17:39Z")
All good ideas. I personally really liked the older voice allocation algorithm (“sticky”) although I have to admit that it is certainly niche and agreed completely with the community it was right to restore “round robin”. Ironically the synth started life as round robin. I do listen I promise! ---
**Author:** ![Quatschmacher](https://avatars.discourse-cdn.com/v4/letter/q/85e7bf/32.png) [@Quatschmacher](https://forum.udo-audio.com/u/Quatschmacher)\ **Post date:** [9 January 2025 08:23 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/6 "2025-01-09T08:23:58Z")
Coming from piano I also prefer the per-key allocation for many applications. Is there scope to have both options available on a per-preset basis? I think I fleshed out a UI idea which would allow that in a post on here a while ago. It may have been something like making the voice mode button selection happen upon release so that you could add a long press function to it. Then a long press when voice mode is in poly 1 or poly 2 mode would toggle between round robin and per-key voice allocation modes. Mode could be indicated **either** by a steadily-lit LED for one mode and a flashing for the other mode, **or** by having the LED flash briefly upon selection thusly: flashing once indicating RR mode, flashing twice indicating per-key mode. It’s a shame unison size isn’t a shift function of the unison button as that would allow voice allocation mode to be a shift function of the voice button. ---
**Author:** ![GregVDS](https://avatars.discourse-cdn.com/v4/letter/g/90db22/32.png) [@GregVDS](https://forum.udo-audio.com/u/GregVDS)\ **Post date:** [9 January 2025 15:05 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/7 "2025-01-09T15:05:33Z")
Thanks for the feedback, George (I suppose 🙂 ). I would really like to see this back as a choice in a config file, something like VoiceAllocation=sticky #rrobin / sticky In the meantime, my Super Gemini has arrived and I intend to deepdive this weekend in it 😊 ---
**Author:** ![GregVDS](https://avatars.discourse-cdn.com/v4/letter/g/90db22/32.png) [@GregVDS](https://forum.udo-audio.com/u/GregVDS)\ **Post date:** [10 January 2025 14:16 UTC](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799/8 "2025-01-10T14:16:59Z")
@udo-audio, Here is a proposition of config file with all the ideas I could foster here already 🙂 : # Configuration file for U.D.O. Super Gemini and Super 8 # variables with default values can be entirely omitted (or commented out with #) # version 0.0 # File extension proposal : configuration.csg (or .cs6 for a future trimmed down configuration file for the Super 6) ######################################### ######################################### # General Settings VoiceAllocation = sticky # rrobin / sticky ControlValueOverride = snap # passthrough / snap # MIDI UpperLayerMidiChannel = 1 # 1 - 16 LowerLayerMidiChannel = 2 # 1 - 16 TxRxETransmit = on # on / off TxRxEReceive = on # on / off TXRXENRPN = on # on / off TxRxPTransmit = on # on / off TxRxPReceive = on # on / off LocalControl = on # on / off ExtClockTransmit = on # on / off ExtClockReceive = on # on / off ExtClockStopReceive = on # on / off ######################################### ######################################### # Upper Layer Settings UpperCrossModType = expFM # expFM / LinFM / lin0FM / oscfdbk / bincomb UpperDDS2TuneType = default # default / ratio # Upper Envelope 1 UpperEnvelope1MaxAttackTime = 15 # maximum length of attack time, in seconds UpperEnvelope1AttackCurve = log # log/lin/exp UpperEnvelope1MaxDecayTime = 15 # maximum length of decay time, in seconds UpperEnvelope1DecayCurve = log # log/lin/exp UpperEnvelope1MaxReleaseTime = 15 # maximum length of release time, in seconds UpperEnvelope1ReleaseCurve = log # log/lin/exp UpperFixedEnvelopeReleaseTime = 1.2 # maximum length of release time, in seconds UpperEnvelope1SliderAttackMap = exp # exp/plin UpperEnvelope1SliderDecayMap = exp # exp/plin UpperEnvelope1SliderSustainMap = exp # exp/plin UpperEnvelope1SliderReleaseMap = exp # exp/plin # Upper Envelope 2 UpperEnvelope2MaxAttackTime = 15 # maximum length of attach time, in seconds UpperEnvelope2AttackCurve = log # log/lin/exp UpperEnvelope2MaxDecayTime = 15 # maximum length of decay time, in seconds UpperEnvelope2DecayCurve = log # log/lin/exp UpperEnvelope2MaxReleaseTime = 15 # maximum length of release time, in seconds UpperEnvelope2ReleaseCurve = log # log/lin/exp UpperFixedEnvelopeReleaseTime = 1.2 # maximum length of release time, in seconds UpperEnvelope2SliderAttackMap = exp # exp/plin UpperEnvelope2SliderDecayMap = exp # exp/plin UpperEnvelope2SliderSustainMap = exp # exp/plin UpperEnvelope2SliderReleaseMap = exp # exp/plin # Upper effects UpperDelayType = default # default / Medres / lowres ######################################### # Lower Layer Settings LowerCrossModType = expFM # expFM / LinFM / lin0FM / oscfdbk / bincomb LowerDDS2TuneType = default # default / ratio # Lower Envelope 1 LowerEnvelope1MaxAttackTime = 15 # maximum length of attack time, in seconds LowerEnvelope1AttackCurve = log # log/lin/exp LowerEnvelope1MaxDecayTime = 15 # maximum length of decay time, in seconds LowerEnvelope1DecayCurve = log # log/lin/exp LowerEnvelope1MaxReleaseTime = 15 # maximum length of release time, in seconds LowerEnvelope1ReleaseCurve = log # log/lin/exp LowerFixedEnvelopeReleaseTime = 1.2 # maximum length of release time, in seconds LowerEnvelope1SliderAttackMap = exp # exp/plin LowerEnvelope1SliderDecayMap = exp # exp/plin LowerEnvelope1SliderSustainMap = exp # exp/plin LowerEnvelope1SliderReleaseMap = exp # exp/plin # Lower Envelope 2 LowerEnvelope2MaxAttackTime = 15 # maximum length of attach time, in seconds LowerEnvelope2AttackCurve = log # log/lin/exp LowerEnvelope2MaxDecayTime = 15 # maximum length of decay time, in seconds LowerEnvelope2DecayCurve = log # log/lin/exp LowerEnvelope2MaxReleaseTime = 15 # maximum length of release time, in seconds LowerEnvelope2ReleaseCurve = log # log/lin/exp LowerFixedEnvelopeReleaseTime = 1.2 # maximum length of release time, in seconds LowerEnvelope2SliderAttackMap = exp # exp/plin LowerEnvelope2SliderDecayMap = exp # exp/plin LowerEnvelope2SliderSustainMap = exp # exp/plin LowerEnvelope2SliderReleaseMap = exp # exp/plin # Lower effects LowerDelayType = default # default / Medres / lowres ######################################### #########################################