May be time to fix Surface API for instrument tracks?

[azslow3]

@msmcleod

PMs are not enabled, so in open

Hello Mark,

I have ordered NI m32... for other reason then Cakewalk, but remembering all discussions I have decided to check if "normal" (not Mackie based) integration is possible.

I will need to know (from API) if current track is related to some synth. I know there is command to open related synth, but I don't know how to get the synth in question from API.

That remind me about old standing issue. For that purpose I was using hack method and it was working in Sonar X2, but that is no longer working in current Cakewalk (from what I remember since long time).

The following is comparison for 3 calls in X2 vs Cakewalk:

GetMixParam(.... MIX_PARAM_INPUT ...)

•  X2 for MIDI track: -1 (somehow not tracking changes in input)
• Cakewalk for MIDI track: MIDI inputs (correct)
• X2 for Instrument track: index of MIDI track output (so usable to identify the synth)
• Cakewalk for Instrument track: ??? seems like index of MIDI track output dependent, but see later ???

GetMixParam(... MIX_PARAM_INPUT_MAX ...)

• X2 for MIDI track: MIDI inputs count (correct)
• Cakewalk for MIDI track: MIDI inputs count (correct)
• X2 for Instrument track: MIDI outputs count, so usable with value
• Cakewalk for Instrument track: ??? some number which i was unable to correlate ???

GetMixParamValueText( ... MIX_PARAM_INPUT ...), using the value from GetMixParam

• X2 for MIDI track: "--- none ---"
• X2 for Instrument track: the name of MIDI input with the same number (as mentioned, the number is from MIDI outputs set)
• Cakewalk for MIDI track: correct MIDI input name
• Cakewalk for Instrument track: as with X2, the name of MIDI input for provided number

 

I think fixing everything means:

1. Report MIDI input as the input for MIDI and Instrument tracks (with correct MAX).
2. Add a method to detect that track is Instrument (may be already exist?)
3. For any track add "Get Related synth" method (for Instrument tracks may be also "Set Related synth" method) (may be also exists?)

 

But for the moment I will be satisfied just with (3) 

Regards,

Alexey.

[msmcleod]

I'm not sure this is always possible for MIDI tracks, the reason being that they can be routed to a hardware MIDI output, a synth MIDI input, or a drum-map MIDI input.

The MIDI output ID's always start with the hardware outs, followed by the soft-synths, then the drum-maps.

The complication comes with drum-maps, as they could be routed to more than one synth.  This would then involve traversing through the topology graph to see what is connected to what, which is a relatively slow process, and not something you'd want to do on a control surface polling cycle.

I think the best that could be done, would be to return the synth rack index for a particular MIDI track only if it's directly connected to it.  You should then be able to get the rest of the information using the existing API calls used when dealing with the synth rack.  I guess the same could be done for audio tracks fed from the synth rack.

BTW - I'm not sure what's happening with MIX_PARAM_INPUT_MAX  for MIDI tracks, it looks like it always returns 17, and I'm not sure why!

[azslow3]

I also think drum-maps can be excluded from matching, so MIDI directly connected to soft synth, Instrument tracks with the synth and probably audio tracks with input from the synth should return the synth id in the rack, everything else can return -1.

That will match behavior of NI keyboards in other DAWs. While theoretically there can be audio and MIDI sends, only tracks which physically host KK are considered (as far as I know, may be in some DAWs that is different...).

DM is in any case just a workaround for not existing MIDI routing and strange MFX format in Cakewalk...

[azslow3]

Well, if you can fix existing for decades bug with "focus related synth", auto instance tracking can be implemented with current features.

The bug: if Context API is used to Focus related Synth, the synth is focuses but ACT mapping is empty. Note that Open (with the same API) and focus with mouse don't have that bug-