#31 Update to Bug 30 [LV2 plugin in Qtractor - state not saved correctly]
Sorry to bother you again but I'm still having problems with this. This time, however, I have some more concrete info as I can reproduce it 100%. Yoshimi is now notifying Qtractor when a change is made, making the session dirty, but I'm seeing the below two specific issues:
ISSUE 1
1) Open Yoshimi LV2 plugin in a Qtractor track; choose patch other than Simple Sound
2) State > Save > [save state]
3) Make change in Qtractor to dirty session (I'm soloing/un-soloing a different track), then save
4) Re-load Qtractor session and open same plugin - patch will have reset to Simple Sound
5) Other instances of Yoshimi in other tracks will be unaffected
In contrast, if you don't save the state, or if you save the state but don't then dirty/save the session, upon re-loading the session the patch will restore correctly. I've tried this on a couple of different sessions, including the one originally uploaded and a completely clean one, and can reproduce this 100%.
ISSUE 2
Yoshimi doesn't notify Qtractor of changes within Scales > Show Settings. It seems that no matter what you change here, Qtractor will be unaware. In addition, after making a change in the Scales menu, such as enabling Microtonal and loading an .scl, upon re-loading the Qtractor session the textual info in the Scales menu will be restored (at least it seems correct), but the .scl file will not actually be loaded. You can test this by playing a few notes - they'll be in 12-TET. You need to tick/untick "Enable Microtonal" to force the settings to re-load.
n.b. this occurs even without performing any kind of state save (i.e. it seems unconnected to ISSUE 1). When proceeding as per ISSUE 1, scale info will also reset to default, as per the patch info.
FYI, in terms of my set-up:
- running Yoshimi 1.5.2 (from git)
- running latest Qtractor git version
- Yoshimi settings: in Yoshimi > Settings > MIDI, have everything unticked apart from Show Learn Editor
- Qtractor settings: in Track menu, have Instrument: (No Instrument), Bank (None), Program (None)
...so program/bank changes can hopefully be discounted as the culprit this time.
By the way, I realise you must be busy getting ready for LAC, so some time after you get back would be fine - I'm not in a huge hurry.
On Sat, 13 May 2017 11:59:02 +0000
"yubatake" yubatake@users.sf.net wrote:
There are two issues (and indeed two state save mechanisms) involved here. When
working as an LV2 instance the host defines the state location and you should
not use yoshimi's own ones, othewise you do in fact save the changes and
clear the flag but to yoshimi's location not the hosts. If under these
conditions you dirty the host it will instruct yoshimi to reload the state from
the host's location, thus overwriting your changes. I'll make a note about this
in my to-do list, but there is no easy solution as a user may want to save
and load using either!
Scales are already on the to-do list. They haven't been touched for a very long
time as they are a nightmare mixture of integers, floats, fractions and...
numbers represented as plain text!
However, a workround that will deal with this is to just nudge any of the
'normal' controls like volume/pan etc.
Indeed, and working to push out V1.5.2 in plenty of time - looking forward to
LAC hugely too :)
Just picked up on the 2nd part of scales.
Originally loading scles never performed an update. We fixed that a couple of years ago, but it looks as if loading from state doesn't include that fix - on the todo list now.
Thanks for the quick response.
ISSUE 1
Thanks for the information. I'm not a developer so am not that familiar with the mechanisms involved. I've been regularly saving states after making changes to avoid losing work due to patches "randomly" (or so I thought) not restoring, but it seems this practice has actually been making things worse :-( Until this can be addressed (if it turns out to be possible), I'll have to avoid saving states in Yoshimi and just save them at the end of a project for archive purposes.
ISSUE 2
Thanks for adding this to your (no doubt very long) list. I'm working on a microtonal piece so it's a bit of a pain to have to disable/enable the scales every time I reload the session, but I can live with it for the moment.
By the way, I tested further your idea of just using 1 instance of Yoshimi in Qtractor's Master Out bus and it works, but for my situation it looks like I'll have to continue having separate instances in each track, due to the way Qtractor works. If you are interested in the full reason why...
Sending all MIDI data from tracks to a bus means that you can't then treat the signal further in the track (e.g. via plugins), as it goes straight to system-out afterwards. As far as I know, there's no way to route the signal back into the track (routing in Qtractor is fairly fixed, as you may be aware - this isn't a Yoshimi issue), unless perhaps via dedicated outputs and I'm sure Rui's advised against this kind of thing in the past. In any case, even if it worked, using dedicated outputs means that you can't export MIDI tracks directly to an audio file - you'd have to bounce to audio within Qtractor prior to final export, adding another step to the workflow. So for my projects, where I need to treat the signal with plugins/Aux Sends, I need to have the sound source in the track. Therefore, I'll have to enable scales/address any other issues for each track each time I re-load the session, which is not much fun when using a lot of tracks as I often do, but I'll persevere and see how it goes :-)
OK, scales re-loading fixed in the current master. LV2 uses a different system to everything else, and we'd forgotten to update the partmaps. That was why it was showing as correct but not actually doing anything.
You still have to twiddle something else to let qtractor know something has changed. Revising the whole of scales is high on my to-do list.
Thanks very much for this. Have tested the new build and it looks good. In terms of the functionality this is very usable for me now, as I know how things work and what the limitations are, so even if Scales end up dropping down the to-do list (I imagine they're not important for the majority of people) it's no problem for me personally.
Scale changes now directly recognised, so I'll close this.