MultiPlay - New Version In Development

[David Duffy]

Most standard cue linking would only benefit from a post-wait. But... you could have several control commands in a row, having a pre-wait for each (and set to an advance action of start play). This means that they would each be offset from the original GO, instead of the completion of the previous cue.

 

I agree that a manual GO should bypass any pre-wait time that was set for that cue. If either (or both) of the waits were implemented I think that the advance actions would need extra entries for the new potential trigger point(s).

[alistermorton]

I use prewait in qlab when I want to use the same trigger to start two cues but want one cue to be delayed relative to the other.

[David Duffy]

Something else I've been pondering is a change to the Cue Properties window. Adding extra features and finding room for them in the GUI can be a challenge. I currently have some of the common properties at the top of the first tab, but there's more of them on the Notes and Triggers (now called Advanced) tabs.

 

How would you all feel if I made the Cue Properties window wider, but not as tall and with more tabs? Then the common properties could be on their own tab(s) and the cue type specific properties on their own tabs. The window shape change would also help with lower resolution screens as it won't take up as much vertical space.

[David Duffy]

I've been working on the new Cue Properties window, so some more musings...

 

The audio cue and playlist cue are 95% the same, so do we need both? An audio cue is effectively a playlist cue with just one track. The Cue Controls panel can enable the Prev and Next buttons when there is more than one track. I'm trying to simplify things in code and I think it should be reasonably intuitive for the end user.

 

Similarly I'm looking at combining some of the other cue types, mainly the network types for now. You'd choose the type of message (Telnet, OSC, etc) inside of the cue. This could make things more easily expanded later (plain UDP, etc) and the cue list part stays the same.

[alistermorton]

I think you can "relegate" some settings away from the main cue property tab; if someone needs to change them they aren't exactly hidden.

 

I think there's also something to be said for a button to switch from editing and running a show, so that all the superfluous stuff that you need when setting up a show but don't need when you actually run the show can be hidden.

[David Duffy]

Can I please get some MultiPlay production files emailed to me (david at da-share dot com) so I can test for compatibility when opening in the new version? The old file extension is xml and the new one will be mpp (at this stage).

[David Duffy]

A question for those interested in OSC cues. Would it be useful if I made it so an OSC cue could have a list of OSC messages instead of just one? They would share a common host, but the address and parameters could be individual per line. This would make it the same as the MIDI cue.

[David Duffy]

May I suggest you set up a basic develop/support forum page for users to contribute their ideas ets. as well as supplying a donation address (Paypal?)

 

I've just added a forum to the da-Share web site so the release info, feature requests and bug reports will be in one place.

 

User registrations will need to be approved. Hopefully it will not be too much for me to maintain.

[alistermorton]

I can see multiline OSC cues having a use, yes.

[David Duffy]

I'm in the midst of changing the OSC cue to a more general network cue as I've been asked about UDP cues. This should be a bit more versatile in the long run.

[kitlane]

A question for those interested in OSC cues. Would it be useful if I made it so an OSC cue could have a list of OSC messages instead of just one? They would share a common host, but the address and parameters could be individual per line. This would make it the same as the MIDI cue.

 

Definitely. I recently did a show where we were controlling distributed video playback from 9 Raspberry Pi's each of which needed its own OSC command, so sent up to 9 commands in one cue.

[David Duffy]

That would have required sending messages to 9 different IP addresses ?

[Just Some Bloke]

Hi David.

 

Firstly, thanks for everything you've done with the software up to now. Secondly, can I request an added feature? On Playlist cues (and I totally agree that these could easily be merged with Audio cues), is there a possibility of being able to set a crossfade time between tracks so, for example, if you set the time to 3 secs, then the last 3 secs of the previous track would crossfade with the first 3 secs of the next track. This would be perfect for walk-in music to ensure the auditorium never goes silent.

 

It would be ideal if you were given the choice of either setting a global time or choosing instead individual times per track, but even if it were globally set only that would still be a really useful addition.

 

 

Hopefully others will agree that this is useful!

[Nid]

...Hopefully other will agree that this is useful!

Very useful indeed!

 

MP is my default program player, but when I have to play continuous background music I switch to WinIsd as it has a nice Xfade plugin.

And speaking of playlists, If a playlist could be edited while active/playing (like Winisd..) that would be also very handy.

 

:)

[bruce]

 

I think there's also something to be said for a button to switch from editing and running a show, so that all the superfluous stuff that you need when setting up a show but don't need when you actually run the show can be hidden.

 

That’s exactly what Qlab does - there’s an “edit” mode and a “show” mode - in Show mode, all the superfluous stuff disappears, and the buttons become a bit more difficult to miss!

 

That’s also helpful if you’re running on a touchscreen device.