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.

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.

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.

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).

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.

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.

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).

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?

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.

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.

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.

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?

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.

It was such a rush with EOFY this week I completely forgot to upload the new version! LINK

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.

Thanks for the feedback Eddie. The video cue in 2.5.5.0 never worked properly and yes the audio was terrible with mp3 files on anything other than XP systems. I'm yet to test the new version with lots of different file types, but it should be ok. The whole $Media folder thing needs revisiting and it always had some quirks.

That's pretty much what I was thinking. A new file extension and some version numbering to enable warnings.

Yeah, the layout / appearance was the main one I was wondering if it should move to general preferences. Speaking of templates, I had the idea of being able to import parts of the preferences / production from another one.

Telnet cues and patches are working now. Some feedback on how people use them would be good. I think the OSC control / cues will open up a lot of possibilities for interaction with other systems. Good to know about the OS usage. I'll have to make up an XP box to try the new version on.

OSC cues and control are working now. Telnet control is also now working. Telnet cues / patches are on the to-do list. Serial cues / patches will worked on soon too. I'm still looking for discussion on the production vs general preferences.

Since I'm rewriting a lot of code, I *could* use this opportunity to change the production file format to enable more flexible cue actions. If so, I may be able to provide a one way (old -> new) format conversion to bring in existing productions. I'd also like more feedback on what cue types you do and don't currently use. And I thought I was old school in not going to Win 10 ! ** laughs out loud ** :) I'll have to dig out (or make up) a box with XP on it. I have XP as a VM on the server, but not sure if that would be a good test. **EDIT** Now that I'm looking at the production file format, I'm wondering if everything that isn't cue list related should move to the general preferences instead? Hot buttons (button layout) would stay with production. Appearance (colours), triggers could go either way. Things like audio/midi/serial/telnet patches are pretty machine specific. Comments please?

I wrote yet another related app today called da_Launcher. You can send it OSC messages to launch a program the same way the Launch cues in MultiPlay already do. So now you'll be able to use the new OSC cues in MultiPlay 3 to launch things on other computers on the same network. I'll release that one this week.

The new version is being developed on Win 7. I have not tried it on Win 10, but don't foresee any issues. Is anyone still using XP ?

You'll like the new version even more then. I'll upload it this week. :) It can store a list of hosts and addresses that you can choose to save typing them in each time you use it.

When I was adding OSC control capability to MultiPlay 3, I needed a way to send it OSC messages. I had a look around for something existing but they were either dead links, needed Java to work, etc. So I've written a little Windows program called da_OSC. Currently it lets you compose an OSC message with up to 4 arguments and send it to a specific host, port and address. You may find it useful for confirming what messages your OSC enabled hardware or software accepts. I'll probably add an OSC monitor window to it in due course so you can see what OSC messages are being sent as well. Version 1.0.0.0 of da_OSC is available now on the da-Share web site.