Midi Crashing SCS10.1.0 (fix in 10.1.2)

[frfortes]

Mike,

I'm using Windows XP SP2, M-Audio Delta 1010LT, Yamaha O1V96 Midi out to Delta 1010LT Midi in
I tried different configurations but SCS 10.1.0 is crashing when it receives a Midi message. Strange fact is that if I open the test midi input I can see the messages, but otherwise it crashes. I uninstalled all Yamaha drivers and software and I don't have any midi related software running. I tried uninstalling and reinstalling SCS 10.1.0 withou success.
Now I'm back to version 9.5.3 and everything is working fine.

Also, I've got some error messages when adding a sound sub cue (to a already sound cue):
Erro 6 Overflow
SCS 10.1.0
ProcName=QF.setViewControls[15<2>]
CueFile

Hope it helps. Unfortunately I don't have time to run a tracing version now, I just want you to know. I can test it in my notebook as soon as I have time.

Fernando Fortes

[Nick]

Hi Fernando,

I have discovered the same thing in production this week - and reported it to Mike on Tuesday. I found however that you can fix it if when you start SCS, and BEFORE sending any MIDI to the attached MIDI interface (whether it is aimed at SCS or not), do the following. Go straight into the Preferences / Midi Control / Test Midi window, and then send a MIDI message to SCS, you can then close out of the preferences window and SCS will respond just fine to MIDI from then until you restart SCS, when you have to do it again. This was the case on two separate computers, running XP, and using MOTU 828s as midi interfaces.

I'm sure I tested MIDI control during beta testing of SCS 10, so it must be a little glitch that crept in somewhere along the line.

_edit_
Mike - the Overflow error Fernando reports sounds like the same situation I reported to you at the same type as the above (but didn't get a chance to write down the details). I was adding a subcue too.
Cheers,
nick

[Mike Daniell]

I encountered similar MIDI crashes when I was testing the new code for MIDI control of the Master Fader. I have now changed the order of events regarding MIDI control, so could you try this again in 10.1.1? Also, I found a potential cause of the overflow error in QF.setViewControls so I have fixed that as well.

[frfortes]

Dear Mike,

Fast as always.

I will check the new version late today.

Thanks in advance,

Fernando Fortes

[Michael Miceli]

I had the same problem with 10.1.0 as described here. Update for 10.1.1:
No more midi crashing. Only remaining symptom and problem is this; I have a cue with 6 lines of audio(L, R, Ls, Rs, C, Sub) 1st line is an Audio cue, the rest are sub-cues. If I play with the GO button in SCS, all is good. Individual outputs all go to where they are mapped(I am using a Presonus Firebox, asio outputs1-6). I have a cue list of three of these multi-track cues, along with fades etc for testing purposes.
Now, I use Palladium for triggering and console control. I am using MidiYoke to send the triggers from Palladium to SCS. If I send a GO (NEXT) trigger from Palladium, any cue in the SCS list will play fine, all 6 outputs functional and linked. IF however, I send a Specific note on for say Cue 3, then ONLY the first line of audio actually PLAYS SOUND, but ALL linked files look like they are playing, ie the timelines are all moving. This is repeatable, and is the case with every cue of this type.

Also, I was receiving the same error messages with the previous version as mentioned above, but no longer.

Kudos on version 10! It's a great leap forward, and has some really nice features (LOVE the looping with crossfade!). Can't wait to try out the video cues. Note of comparison between SCS and some other programs (SFX 5.6 and 6)- SCS seems more susceptible to audio dropouts due to system calls. I had to use the DPCLAT utility to find out that I had issues related to the wireless nic card with SCS. I can run all the hardware with no problems with the other packages. Just FYI.

[Mike Daniell]

Now, I use Palladium for triggering and console control. I am using MidiYoke to send the triggers from Palladium to SCS. If I send a GO (NEXT) trigger from Palladium, any cue in the SCS list will play fine, all 6 outputs functional and linked. IF however, I send a Specific note on for say Cue 3, then ONLY the first line of audio actually PLAYS SOUND, but ALL linked files look like they are playing, ie the timelines are all moving. This is repeatable, and is the case with every cue of this type.

Confirmed - I've been able to reproduce that. I'll sort it out over the next few days.

Note of comparison between SCS and some other programs (SFX 5.6 and 6)- SCS seems more susceptible to audio dropouts due to system calls. I had to use the DPCLAT utility to find out that I had issues related to the wireless nic card with SCS. I can run all the hardware with no problems with the other packages. Just FYI.

Do you have any info on what system calls were causing the audio dropouts?

[Michael Miceli]

Main culprit was the internal wireless. It seemed responsible for major peaks while everything else, usb devices etc, were only making small peaks.

[Michael Miceli]

Following up on the midi firing of cues. I'm currently in tech for a show and am firing the cues with just a "go" trigger, but am not ultimately going to want to leave it that way, preferring instead, if possible, to fire the cues individually with specific midi commands. Any idea of the realistic timeline for finding a cure for this specific behavior? I saw reference to 10.1.2; how close are we to a release of that, and will it address this?

Thanks for all the updates and attention to these details!

Best,
Mike

[Mike Daniell]

10.1.2 will be uploaded later today.

EDIT: The issues mentioned in this topic have now been fixed in 10.1.2.

[Michael Miceli]

Kudos! Nice work. Midi triggers working perfectly.

Thanks!

Mike