Store play mode, portamento, and PB with patch

bolau	Posted on Sun 20 Mar 2022, 04:38 PM Hi, I try to understand, why the play mode (Poly, Mono, etc.), Portamento, Pitch Bend Range aren't stored with a patch. For me it's an integral part of the sound design. When I play live, I'm in the performance mode and recall patches on different MIDI channels on the fly via program change commands. But then I have to readjust play mode, portamento and pitch bend before I can really play that patch properly. That just doesn't make any sense to me. Could this be changed in the future? Please? Best, Boris
KODAMO	Posted on Mon 21 Mar 2022, 10:38 PM Hi, You can simply setup your different poly/mono settings on a few parts, then use the appropriate MIDI channel for the program change and play. The current design allows to try many sounds using the same poly/mono settings (otherwise you'd have to edit these for every single patch you try)
bolau	Posted on Wed 23 Mar 2022, 01:09 PM I understand that browsing sounds in a "comparable" way is a nice feature, and I think it is very relevant for browsing waveforms or voices and searching for building blocks during sound design. But when I recall a patch while performing, I want it to sound and behave exactly how it was designed. Losing that is a high price to pay.
phosphenes	Posted on Wed 23 Mar 2022, 04:08 PM Having a similar discussion about this in a different topic; thought I'd chime in here. I also understand the logic/design choice regarding why these 'voicing settings' (portamento/pbend/poly/mono etc.) settings are saved for patches at a perf level (4080 unique save states for all of these settings within the 255 perf patches?), rather than being saved per layer within a patch, (think it's something like a possible 400k unique states!). I could also see the logic of having the 'voicing settings' contained within the save state of voices, (which I think could allow for patch recall with 'voicing settings' as designed as bolau mentioned). Think there would actually be less save states for the 'voicing settings' settings (3302?) if the 'voicing settings' settings were stored per voice. In my opinion, 'voicing settings' stored per voice would also be more intuitive from a user perspective. In theory, would 'voicing settings' stored per voice allow for patches that contain voices with unique 'voicing settings' mapped to different sections of the keyboard, without filling up multiple perf slots? In practice, it's been confusing to make multiple related patches with specific keyboard ranges, and to then assign those patches into a performance. Moving those sets of patches into different perf patches and individually copy/pasting the attached 'voicing settings' is counter intuitive. Also, because of this save management system, aren't there kind of 'only' 255 unique save states for multilayered, variably mapped patch families with independent 'voicing settings' with the implemented save architecture hierarchy? The 'voicing settings' 'per voice' workflow I'm attempting to describe is achievable on workstations/multitimbral instruments I've used before; but I also totally understand that every instrument is unique. Further, I have no idea how the optimisation works within this instrument, and I suspect this is maybe the reason why these settings are only saved at the highest level of the save hierarchy. As right now, I honestly find having the 'voicing settings' accessible within voice/patch mode more of an inconvenience than a benefit as they are un-saveable, and un-transferrable without multiple unique copy/paste actions required to port the settings into a perf patch. There's also the voice sequencer; other than the first note of the sequence, the voice sequencer is always poly with 0 portamento, regardless of 'voicing settings'. I find this very confusing. Having the 'voicing settings' saved per voice could, at least in theory, allow for 'mono' layers in the voice sequencer. Cheers, R