On Song Change - Initial Variation Setup Not Working

[progster]

Hi.

I am observing something in Setlist mode that is not behaving as I would expect.

I have Songs set up with parts:

Each part sends an initialization message downstream, out a MIDI port to external software.

Now, when I mouse or arrow around between the Song Parts within a Song, everything works perfectly. I see the desired message go out in the Global MIDI Monitor, and the downstream software receives and acts on the message (changes scene).

So far, so good.

However, when I first go to a new Song, the downstream software does not change scene to match that first variation of the new Song.

As before, now that I’m within a Song I can switch variations and everything works, but again on changing Song the action of the setup specified by arrival at the first variation does not happen downstream. (i.e. the scene does not change)

Strangely, the Global MIDI Monitor shows the setup message being sent in all cases. One might say “Well, that means the problem must be downstream”, but recall that within a Song, downstream is working perfectly.

Why would the behavior differ when first arriving in a new Song?

Could the Global MIDI Monitor report sending a message that did not actually get sent?

Could the timing of all the data being sent out be relevant?

Here is a sample picture of the scene message seemingly going out on Song change,but without the scene change actually taking place.

Subsequently, I click on Parts s2 and then click on s1 (within the Song) and both operations work perfectly.

The famous words “Something is different” come to mind, but what is it?!

[rank13]

@progster

Could the Global MIDI Monitor report sending a message that did not actually get sent?

If you’re doubting the Global MIDI Monitor, install Protokol and have it display what is being sent to your loopMIDI port.

[jeffn1]

Could be totally off base, but…

I recall discussions where a command was sent too early so that it did not work right(?)

Maybe try adding a time delay for the message to be sent. (newly added to GP).

Repeat caveat: I could be totally off base. Feel free to ignore.

Jeff

[edm11]

Echoing the sentiments of @rank13, you can check with Protokol…but really, if the Global MIDI monitor shows the message sent, it sent. So yes, the issue is downstream. The question is why isn’t it being received? Whether that be something else intercepting the message, or the receiving device not being ready to receive the message, or something else is to be found out. But its downstream.

If you use Actions in your Song Parts instead of your current method to send the MIDI messages, you can incorporate a Delay action prior to sending the message, as @jeffn1 suggested.

[progster]

@rank13

install Protokol and have it display what is being sent to your loopMIDI port.

Ah, I didn’t know about Protokol. Done. Thanks!

[progster]

@edm11

If you use Actions in your Song Parts instead of your current method to send the MIDI messages, you can incorporate a Delay action prior to sending the message, as @jeffn1 suggested.

Thanks Jeff and Ed!

Indeed, if I use a 3 second (!) delay at that point (via Actions) the scene change takes place.

I will have to deal with the implications, but the facts now seem clear - changing Song = Changing Performance (downstream), which takes longer to settle in than merely changing scene (downstream). Ha!

Thanks again!

[dhj]

Wow…what exactly needs three seconds to change?

[jeffn1]

Wow, I got lucky with that one! But, like David suggested, have you tried less delay? I would think in terms of fractions of a second. (But, I defer to David for real info.)

Jeff

[dhj]

I know that some really old synths (going back 3 decades at least) could take a moment to respond to a program change but a three second delay in this day and age seems absurd

[progster]

@dhj

Wow…what exactly needs three seconds to change?

Took me awhile to see it, but eventually this tipped me off that I needed more time:

This is Karma Motif software (on the other end of a virtual pipe) driving a real Yamaha Motif XF synth. When Performances (top level) change, both the software and the hardware need to be configured, and that’s what is taking the 3 seconds.

Inside a given Performance, scenes change at the barlines, nearly instantly.

[progster]

Allowing a single delay Action to be set longer than 1000 ms would be nice here, but since the delay Actions easily duplicate, it’s not a big deal.

The ideal of savable/loadable “action sets” also comes to mind.

[progster]

But if this aspect of Song Parts is going to remain with us:

then being able to give it a delay setting (of sufficient length) would perhaps be most flexible here in the field, as Song Parts can be moved around and it is only the first one (which can change) that needs this delay.

[dhj]

The max delay was deliberately set to one second. Actions trigger synchronously. So if you put in a delay, all future actions that are pending will be delayed and we did not want a situation where actions could be held up to a point where the system would essentially not work, even if it was user error. The assumption was that most delays would be in the millisecond range, perhaps 50-200 ms. Something that take three seconds to respond is a seriously unusual outlier.

[progster]

Trying to use SendLater() in my gig script as an alternative here. It doesn’t compile.

Should I be using a different script other than the Gig script for this?

[progster]

It looks like I need:

SendLaterToMidiOutDevice( KMo_OutDev, Scene_Msg_01, 3000 )

but that does not exist, right?

Perhaps it could be added?

[dhj]

SendLater is a hack - it’s not going to get any improvements.
At some point, we’ll build a proper scheduling mechanism into GPScript but it’s not high priority.

Again - you should be building an extension using the C++ SDK. I don’t know what exactly you’re developing but based on your questions, my sense is you’re trying to push GP Script to do stuff that is far beyond what was (and still is) its intent.

[progster]

The only thing I’m trying to do here is to use Songs and Song Parts, in accord with their paradigm, but with something downstream that needs a bit more time to setup. I’m surprised this is turning out to be “exotic” in any sense of the word.

[dhj]

@progster

The only thing I’m trying to do here is to use Songs and Song Parts

I’m referring to your overall project, not just this small part of it.

[vangrieg]

@dhj

At some point, we’ll build a proper scheduling mechanism into GPScript but it’s not high priority.

I so wish this point comes sooner

The workarounds using ramps and timer are extremely cumbersome if you need to do that kind of stuff more than once.

[vangrieg]

@dhj

you should be building an extension using the C++ SDK

You say that often.

But GPScript is one of the reasons I use GP, it’s important because it’s a way to close the functionality gap. And extension SDK doesn’t provide much on top of GPScript in terms of functionality, yet the overhead of moving to C++ is huge for anyone who’s not super familiar with it.