# Boot drive configuration file ideas

**URL:** <https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799>\
**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:** 1\
**Showing post:** 3

<div class="post-metadata">

**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")

</div>

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?

---

_[View the full topic](https://forum.udo-audio.com/t/boot-drive-configuration-file-ideas/2799)._