I have an issue with the MIDI Remote API. The callback function mOnChangePluginIdentity returns incorrect values in certain circumstances.
I have a controller with one page for insert effects and one for sends (created with mMapping.makePage()).
Here’s how it fails:
I have two audio tracks, each with two inserts in slot 1 and 2. “Audio 01” is the selected track.
With my “Inserts Page” active, I invoke mAction.mNext on my InsertEffectViewer object to set focus on insert slot 2.
I change my page to my “Sends Page”.
I select the next track, “Audio 02”.
I change the MIDI Remote Page back to my “Inserts Page”.
The callback function mOnChangePluginIdentity returns the plugin name and vendor of the previous track, “Audio 01”.
I invoke the mAction.mPrev to set focus on slot 1.
The mOnChangePluginIdentity still gives me plugin name and vendor from the track “Audio 01”
It seems that if the “Inserts Page” is not active when selecting a new track, the ’ InsertEffectViewer object is not properly updated.
I have tried to experiment with mAction.mReset.trigger() in various places to no avail.
Of course I would actually update the title and add the “Issue” tag.
The expected behavior should be that when we activate the “Inserts” page, we would get the insert slots for the currently selected track and not the one that was previously set. Furthermore, ideally, the insertsViewer could get us back to whichever slot we were previously working with in this track.
Workaround? When I scripted for the SL MK3, I completely abandoned the flow of mapping pages and made everything available in one page with multiple subpages. This way, I got rid of an issue with the mixer bank zone resetting upon a page change, and at the same time my insertsViewer was getting updated as expected. However, the slot number is kept to the previous one we had. It doesn’t bother me much, we can always reset it upon the subpage activation.
The problem is that by taking the approach of subpages, makes the mapping assistant unusable to a large extent, since when we remap, it affects the whole page, not the currently selected subpage. I don’t mind, since my script was created based on my own flow, however, it surely affects users who wold like a more friendly assigning process.
@m.c Thank you for confirming. I will look into restructuring my script to only use subpages.
I thought about this and I think I prefer to have it not reset when changing a page or selected channel (or banks if one uses those).
This won’t be a problem for me personally since I bind all the Cubase parameters to custom value variables anyway and the mapping assistant does not work with those.
Sure, but let’s consider an example:
Say, we have one track with two inserts and we navigated to the second. Then we go to another track which has only one insert (say slot one). The thing is that when we do this, we will still be at slot 2. Again, not a big deal, we can always use navigation assignments for going where we want, I just mentioned it to show that using subpages is not a solution that fixes everything.
Your example is true if we just use pages as well and is a scenario I am familiar with.
I would still not prefer it to reset to slot #1.
The likelihood that I want to go back to the first track with slot #2 active is quite large.
In my setup, my controller shows the current slot number and all the LEDs turn off if the slot is empty. It doesn’t feel like an obstacle.
But it’s a good thing to keep in mind and consider. Personal preference I suppose.
We could reset the insertsViewer if the current slot is empty as well if we want to. There is of course a chance that slot #1 is empty as well!
There is also a new addition in the insertsViewer you might want to check out: We can now access distinct slots directly, by creating an insertsViewer just for one slot, here’s an example:
var insertsViewerSlot1=pageInserts.mHostAccess.mTrackSelection.mMixerChannel.mInsertAndStripEffects.makeInsertEffectViewer("insertsViewerSlot1")
insertsViewerSlot1.accessSlotAtIndex(0) //Index is always 1 less than the slot index
//This insertsViewer will be assigned to slot 1
var insertsViewerSlot2=pageInserts.mHostAccess.mTrackSelection.mMixerChannel.mInsertAndStripEffects.makeInsertEffectViewer("insertsViewerSlot2")
insertsViewerSlot2.accessSlotAtIndex(1)
//This insertsViewer will be assigned to slot 2
That looks neat!
I suppose that means we don’t have to use insertFxViewer.mAction.mPrev and insertFxViewer.mAction.mNext, but instead map each slot to a sub page if we so choose…? Or am I thinking about this the wrong way?
I would actually update the title and add the “Issue” tag.