MultiPlay - New Version In Development

[JorgeASilva]

Hi everyone!

 

 

My main PC has windows 8.1, but I've used MP in xp, 7, 8 and 10. I usually prepare all audio to 16bit/44.1kHz so that nothing funny happens. I use several interfaces, the most overwhelming one was a soundcraft vi6 with dante protocol.

 

I've lost track of how many people I've successfully converted to use MP instead of basic media players. Even VLC has some interesting features, but nothing compared to this amazing software. I've used commercial solutions in the past - qlab still stands as a benchmark, in my opinion - but the power of MP is evident when it comes to quickly adapt tracks on the fly, specially with choreographers and directors next to me... And as I use it in this very small and poor country - Portugal is only great in football... - the fact that is free is, of course, undeniably important.

 

Thanks for all the work David (again!) and I'm hoping for a version 3 soon. :)

[dmxlights]

I was following this thread and I have never knew about this program. I may have use for it. I am doing light for a play coming up. If it will play video in the new version. I could see artnet control be very useful.

 

I am hoping to mount a small screen on a stand at the back of the stage which will be used to play 2 different videos of 2 different fires. I do have a windows 7 10" tablet that I could use as the screen also need to kill the backlight when not needed.

 

[David Duffy]

A few more bits are done. The loops column in the cue list now shows the current loop count. This even works when the audio cue is set to infinite loops.

 

I've also added RAM and CPU usage indicators to a "Statistics" window. I wanted to know how the various cues were taxing my system and thought I'd make it a permanent feature. It also show the PC's current IP address which is handy for setting up remote OSC or Telnet control.

 

VU meters and volume controls for the audio outputs is something else I'm also playing with. It may end up becoming another dockable tab. Indication of the OSC and Telnet control ports status would be nice to show somewhere too.

 

The video cues don't work as well as I'd like yet, so I'm investigating alternative methods for that. I may end up writing an OSC triggered video player so that can run on a separate PC.

[willjam39]

HI,

 

Thank you for redoing your wonderful program. I have used it for several years on loads of Am dram shows for Audio and basic serial controls and recommend it to all of my groups. In fact I ran the audio for my best friends wedding off it this weekend so a organist could press play at the right moment.

 

Still using a small Advent XP Netbook but its showing its age with time sync issues.

 

Donation will be sent on payday.

 

Will

[David Duffy]

MIDI sequence cues have been 95% rewritten and can now be panned and have fade-in and fade-out parameters like like audio cues.

 

I'm now working on the MIDI patch list, general MIDI output, MIDI control and MIDI mute.

 

So far I've probably spent 100+ hours on the MultiPlay 3 rewrite.

 

I've also improved the External Tools section with a menu option to open an audio cues's file in the specified editor.

Edited July 4, 2019 by David Duffy

[David Duffy]

Someone asked (via email) about RPN and NRPN MIDI cues. These seem to be a sequence of CC messages so could be done via the current MIDI cue, although I'm guessing it would be easier if people could just key in the parameter number and value instead of working it out each time?

[alistermorton]

Something someone asked for recently in the Qlab group on farcebook seems quite sensible to me, and I don't know if you've implemented it in multiplay, so I thought I'd mention it.

 

It can be useful to be able to mark cues as unaffected by the panic / emergency stop. In qlab the emergency stop by default fades and stops all running cues - I guess the same is true in multiplay - but sometimes you might want to leave a bed track or video projection up even when the panic button has been hit. Having a tick box on the cue to mark it as shielded could be useful.

 

If you've already done this, then just ignore me :-)

[David Duffy]

I can't see any reason I can't implement that function. I have been thinking of moving some of the advanced (and seldom used) cue properties off the front tab, so this could go there too. There would need to be a "stop absolutely everything" button somewhere as hunting down the remaining running cues could be trouble for the operator.

 

In the Output column of the cue list I'm now showing the destination patch for Serial, MIDI, MIDI Mute and MIDI Seq cues.

 

Another thing I've just added is a Mono checkbox to the Audio, Playlist and MIDI Seq cues so they can be run as mono without having to edit the files.

[revbobuk]

David - I'm absolutely sure that most BR folk would be keen to beta test (or even alpha test!) what you are doing. Have you considered releasing an early beta on here for feedback and comment?

[David Duffy]

OK, I have added "Ignore Stop All" and "Ignore Fade All" check boxes to the Advanced (previously called Triggers) tab of the cue properties window.

 

I have also added an new "E Stop" button to the top tool bar which will stop everything, even if cues have the ignore(s) checked. It does ask for confirmation though, just in case you clicked it by mistake!

 

I think version 3 will be good enough for a small scale release / test in the next week.

Edited July 5, 2019 by David Duffy

[alistermorton]

That sounds good, David.

[tonytech]

Again, Thanks again for the hard work.

[David Duffy]

Yesterday (Saturday) was spent adding support for audio tags info, reworking more code, tracking down odd bugs and starting MIDI input for control. Time to have a think about how the MIDI control should be implemented.

[David Duffy]

Something else that's been requested is for cues to have optional pre-wait and a post-wait times built in. I'm guessing that this is to save adding wait cues in between cues that need to be separated by some fixed time. On the surface this sounds reasonable. Comments please?

[sandall]

2 thoughts that occur (ignoring any additional complexities for you David) -

 

Wait-times should only active when cues are linked, so, by default, unlinking would disable any associated wait-times.

 

As adding a post-wait to Cue-1 or pre-wait to Cue-2 effectively has the same result, does having both options risk introducing a potential peasant-trap, particularly if someone else wrote the cue-stack that no longer matches what's just happened on stage? (just a thought)