Re: [Qtractor-devel] LV2-Yoshimi state save/load

[Rui N. C. <rn...@rn...>]

On 04/02/2016 08:08 PM, Will Godfrey wrote:
> On Sat, 2 Apr 2016 17:43:01 +0100
> Rui Nuno Capela <rn...@rn...> wrote:
>
>> On 04/02/2016 04:46 PM, Will Godfrey wrote:
>>> Yoshimi's state includes all volume & pan settings, but qtractor somehow
>>> doesn't seem to restore these. It gets all the instruments in the correct parts
>>> but with pan at centre and default volume. I don't know how it manages to do
>>> that! Both Ardour and Muse get this right.
>>>
>>
>> could it be that yoshimi responds to MIDI channel volume (cc#7) and
>> panning (cc#10) messages ?
>>
>> qtractor does override each MIDI track/channel with those controllers
>> --they're both handled as MIDI track/channels properties for that
>> matter--upon session setup and anytime later, eventually whenever
>> MIDI connections changes.
>>
>> hth.
>
> Yes, Yoshimi accepts most standard MIDI CCs
>
> This is a real problem. Yoshimi state is a very complete setup and is intended
> to restore it to *exactly* the condition it was saved at. If you are changing
> anything at all after the state has been loaded you break Yoshimi's model.
>
> I've had this discussion with other sequencer builders. While I can appreciate
> the desire to put things in a known condition, it's my belief that any such
> changes should only be made *before* a state or patch set load.
>

and why is that a problem at all?

i must say it's been like so since day 0 in qtractor model; it has been 
like so for external soft- and hard -instruments, following the GM/GS/XG 
standard all over; plug-ins are no different either, even though you can 
insert a multi-timbral plug-in on a midi output bus, MIDI tracks volume 
and pan will converge to it on respective MIDI channel basis, so there's 
no escape from that.

otoh. the problem i see is often one of hard-wiring these MIDI 
controllers (cc#7, cc#10) directly to an internal instrument state 
parameters or control ports, whatever--in my (fairy tales) book, 
hard-wired MIDI CC's *should* "modulate" the DSP model variables, and 
never override directly fundamental state model variables.

eg. considering a state_value in the normalized range [0, 1] and 
midi_value in [0, 127] 7bit range, then the  effective dsp_value 
should be:	dsp_value = state_value * midi_value / 127;

thinking of which, you may probably know that doing this MIDI controller 
1:1 functional mapping to a plug-ins internal state is considered 
"serious felony" by the LV2 police, don't you? ;)

cheers
-- 
rncbc aka. Rui Nuno Capela