Temporary storage area for mod voices in patches
pandar1 | I was experimenting with sound editing on the Essence FM and came across something really frustrating when searching for new sounds. You select a patch, start tweaking it, duplicate a layer, and begin modifying it… and suddenly, all the other layers using that voice change as well. I understand how patch and voice management work on the Essence FM—I know that a patch doesn’t store a customized version of the voice but simply references it. However, this behavior is incredibly disruptive. Having to manually find an empty slot, save the voice, and rename it just to keep track of changes really disrupt experimentation. A much smoother workflow would be to store cloned layer/voice parameters in a temporary memory area under the hood, allowing edits without affecting other layers. Then, when saving the patch, the system could prompt to save any newly created voices. This way, sound design would be far more intuitive and efficient. Other request: why I can't save the morpher with the patch? this is a very useful feature when you have multiple layers (like in korg vector synths) and can define the patch and give it movement, so I think it absolutely must find it's way into the core params of the patch. |
jbowman | In my use case I am working on a series of separate tracks, each of which uses the same performance. But for each track I want to be able to tweak the settings of each part in the performance to make the sound fit that track, without altering the sound for all the other tracks. At the moment I have to save the performance into a new slot, and then save each part and voice I want to edit to avoid alterations made for the purposes of the new track from changing the sound of the other tracks. My proposed solution is that when you save performance there should be an option to "Save Editable Copy". Selecting this would save an identical copy of the performance in the next available empty performance slot. It would also automatically save a copy of each part (which is not an init patch) into a new part in the next available empty patch slot. It would then also save a copy of each voice in each part (which is not an init voice) into a new voice in the next available empty voice slot. So the new editable copy performance would be made up of editable copies of each of the patches and voices which can be tweaked without affecting other performances (and the sound of other tracks). If the original performance was called "Track 1" then the newly saved performance would be called "Track 1 - editable". I can then manually rename it "Track 2". If the original part was called "FM Bass 99" then the newly saved part would be called "FM Bass 99 - editable". Same principle would apply to voices. You could have the same option for saving patches ("Save Editable Copy" would just save a copy of the patch and copies of all voices used in the patch to the next empty slots, renamed as "editable"s). For voice you can already just "Save As" a new voice, which gets you to the same place. For me personally this would help my workflow with this amazing synth. It would also encourage me to build out my performances more, since at the moment I have a lot of manual saving to do each time I want to make a new track using the same performance! I can see that as an option it wouldn't be attractive to everyone, but if it is just a selectable option when saving I don't think it would detract from anyone who doesn't want to use it. |
| pandar1 | Yes, your solution is valid as well. The current method is far too slow and disrupts the workflow. In retrospect, a much better approach would have been to save all dependent entities when saving an entity. For example, saving a patch would automatically include all its voices, and saving a performance would encompass all its patches along with their respective voices. Sure, this might use more memory, but flash storage is incredibly cheap nowadays—we’re no longer in the ‘80s when you had to care for every byte. Plus, FM parameters take up only a few bytes, as evidenced by the tiny .efm files. If every voice needs, eg. 1024 bytes to be fully stored, and a patch can contains 128 voices, and a performance 16 patches, and we want 256 performances, total count would be 0.5 Gb... a flash sd of 128 Gb sells for 10 EUR and would be capable to store 65k performances, with every patch and every voice fully customizable inside... The only scenario where the current method makes sense is when you want to modify a voice across all patches that reference it. However, I believe this use case is rare compared to the far more common need to keep voice or patch modifications unique to the patch or performance you're working on, without unintentionally altering previously created ones. |
| pandar1 | Is someone from Kodamo still in da house? 😎 |
Colin Muir Dorward | <blockquote>In retrospect, a much better approach would have been to save all dependent entities when saving an entity. For example, saving a patch would automatically include all its voices, and saving a performance would encompass all its patches along with their respective voices. Sure, this might use more memory, but flash storage is incredibly cheap nowadays—we’re no longer in the ‘80s when you had to care for every byte. Plus, FM parameters take up only a few bytes, as evidenced by the tiny .efm files. If every voice needs, eg. 1024 bytes to be fully stored, and a patch can contains 128 voices, and a performance 16 patches, and we want 256 performances, total count would be 0.5 Gb... a flash sd of 128 Gb sells for 10 EUR and would be capable to store 65k performances, with every patch and every voice fully customizable inside...</blockquote> +1 for this. Would be a massive upgrade. Not to mention the problem of changing a voice, and then every patch which used that voice is now broken or different. |
darthkrimeny | I love my EssenceFM for everything it does, but I wish the patch management was handled a little differently. I used to have a Digitone (sold it for the EssenceFM) and I have a Synthstrom Deluge, and both of those synths use the "no harm" approach to editing: when you want to save a sound (equivalent to EssenceFM's "Voice") you edited, you have to deliberately overwrite the globally-shared sound, because you're actually working with an in-project (basically EssenceFM's "Patch") copy of the sound (Voice). With those other synths, I often find myself tweaking a sound for a particular song but don't want it to affect all the other instance; with EssenceFM, I would prefer if each Voice in a Patch was an in-Patch copy of the Voice and that changes to the Voice would save only in the Patch. I imagine it would take some reworking of the EssenceFM to make it work that way, but that workflow would feel smoother (and less risky) to me. |
Reply
