Miscellaneous OSC questions

@craigr

I will answer very briefly, because I'm busy getting v1.8 finished and out.

1. No
2. See https://ccrma.stanford.edu/groups/osc/spec-1_0.html
3. Yes
4. Would it be difficult? To devise a general solution, which will work in all cases, including when the DAW project is reopened and the Unify instances re-created in a different time-order, yes.

I think what you are actually asking in #4 is Will I do this for you? Short answer: maybe, but not right now.

@getdunne

In the latest beta (244), the change-log says:

• OSC commands can now be sent to embedded Unify instances
  • Use "unify" instead of "plugin", and follow with appropriate OSC command path.

I'm trying to find some more information on this in the manual, but failed.

Can you please elaborate further on this, maybe with som examples?

Posted by: @thsve

@getdunne

In the latest beta (244), the change-log says:

• OSC commands can now be sent to embedded Unify instances
  • Use "unify" instead of "plugin", and follow with appropriate OSC command path.

I'm trying to find some more information on this in the manual, but failed.

Can you please elaborate further on this, maybe with som examples?

We are still in beta (and I just went through a hurricane), so I won't be updating the manual just yet, but the main example is where you set up a patch with two or more INST layers with embedded Unify instances, and you would like to be able to send OSC commands to those two instances separately. For simplicity, suppose you want to send the command /master/mixLevel to two instances on INST1 and INST2. You would do this by sending the following to the containing Unify app:

• /inst/1/unify/master/mixLevel
• /inst/2/unify/master/mixLevel

Note the syntax is similar to parameter-set messages for the plug-ins on INST1 and INST2, but instead of the keyword plugin, I have substituted unify, and the rest of the command is not an automation-parameter name, but another OSC command.

Perhaps the most important case for using this is discussed here in the Forum, where user @craigr68 states that he wants to be able to send OSC load messages to multiple Unify instances (from a custom remote-control program he has written), to script patch loading. The OSC command format would be e.g. /inst/1/unify/load with an appropriate patch-index encoded as the command value.

@getdunne 

Hi,

I’m aware of the ”problematic” weather conditions in your area😱 so I wasn’t expecting you prioritize this. Hope everything is ok now when Fiona has moved on.

The reason I posted this question was that I as a member of the beta team was going to test this. I don’t think that there are many of us that actually use this functionality. I’we tested the previous OSC functionality in different environments (TouchOSC, Python, AutoHotKey and C#) so I’m confident with the basic functionality, but couldn’t get enough information from the brief changelog description to actually see what was changed/added to be able to test it.

For me this is not a big deal and I will probably figure it out in some way.

I will mail John and ask him to remove me from the Beta-group.

Posted by: @thsve

For me this is not a big deal and I will probably figure it out in some way.

Have I not provided enough detail above?

I will mail John and ask him to remove me from the Beta-group.

Have we offended you in some way?

@getdunne 

Just did a quick test with TouchOSC to load INST2 and it works.

No, you have not offended me. Sorry if it sounded like that. It's just that because of how I use UNIFY, I don't feel like I'm contributing enough in the beta process.

Posted by: @thsve

Just did a quick test with TouchOSC to load INST2 and it works.

What happens to all the rest of the settings on INST2 layer when you send the command?  Say you set a specific Midi Channel, key range, etc beforehand.  Then you send the command to load that layer.  Does it retain that info after?  Or are there options to set those as well?

Posted by: @craigr68

Posted by: @thsve

Just did a quick test with TouchOSC to load INST2 and it works.

What happens to all the rest of the settings on INST2 layer when you send the command?  Say you set a specific Midi Channel, key range, etc beforehand.  Then you send the command to load that layer.  Does it retain that info after?  Or are there options to set those as well?

All the things you mention are set in the INST2 layer itself, in the top-level Unify, and hence should not change. The OSC load command (sent as /inst/2/unify/load) only affects the embedded Unify instance on that INST layer.

There are presently no OSC commands to set layer MIDI channel or key range. You would set and save these in the master (top-level) patch.

That's great.  I like how that works.  I'm anxious to give it a try when you get the new fixed beta out.

Fantastic!  Now that I have Beta 245 installed.  I got it working where my two midi keyboards can switch patches independent of each other using the new OSC features.  I have my DX on chan1 triggering Inst1 and my M-Audio OXY61 on chan8 triggering Inst2.  Now I won't have to involve Cakewalk running 2 instances.  I'm also very pleased that switching presets on either doesn't glitch the other one from playing even if I'm loading a large patch.  I set my Alternative Browser so a left click on a patch switches Inst1 and right click switches Inst2.  Screenshot shows Alternative browser behind Unify.

@craigr68

Looks terrific. I'm glad to hear this is working out for you. Any chance you might open-source your custom patch browser/controller program?

It's mostly an Autohotkey script and about 5 other small files.  In the future I might post it to the forum in a new thread.  (Not sure if that's what you mean by open-sourcing it.)  I'll be refining it for a while.  I'd have to clean it up a bit to make it more generic because some code is particular to my computer like file locations, monitor sizes, etc.  In the past, I've posted older midi versions that were more complicated and got some interest.  This OSC version is simpler.  It would help if someone was interested in it, would try it, and let me know feedback.  

Oh, and thanks so much for those new features which made this possible.

Posted by: @craigr68

It's mostly an Autohotkey script and about 5 other small files.  In the future I might post it to the forum in a new thread.  (Not sure if that's what you mean by open-sourcing it.)  I'll be refining it for a while.  I'd have to clean it up a bit to make it more generic because some code is particular to my computer like file locations, monitor sizes, etc.  In the past, I've posted older midi versions that were more complicated and got some interest.  This OSC version is simpler.  It would help if someone was interested in it, would try it, and let me know feedback.

Open-sourcing just means publishing your script(s). Because AHK is a bit clumsy, it might be better to publish a detailed description of your user interface and work-flow, and somebody (maybe me) may be able to reproduce the functionality in an actual app.

Oh, and thanks so much for those new features which made this possible.

You're welcome. As you can imagine, there's no end to the number of OSC commands that could be added, so I'm trying to do it on an as-needed basis. Hence feedback about where you struggle is super-important.

@craigr68 

Hi. I have included the new osc-messages into my "UNIFY - Patch Loader" (former known as "UNIFY - Random Patch Loader" 😀 ). Some minor things to iron out, but here is it how looks now:

[img] [/img]

Will make a short video explaining the functionality soon.

I'm not a programmer.  Just a guy who fiddles with AHK to get my computer to do specific things.  Open source to where?  I would gladly share the work-flow in general terms.  It's the programming details that I struggle with some.

Here's the basic scheme.  The GUI interface is similar to a blown up version of the Unify Browser - in that, a dropdownlist allows the user to select a library.  It retrieves the patches by looping through the Unify library patches.  (This only takes a few milliseconds.  Autohotkey uses Loop Files and Listview commands to do this.)  To send a OSC patch change, Unify needs to be open with a patch like I show in the screenshot above with 2 instrument layers.  A left click sends the rownumber to /inst/1/unify/load and a right click sends rownumber to /inst/2/unify/load.  The patch rownumber has to be retrieved from the database.  That part I'm having a bit of difficulty with.  Currently I'm searching patch name and library from an extracted .csv version of the database in order to get the rownumber.  But if the database ordering changes, from an add for instance, I have to update that csv file.  It would be much better if I could retrieve rownumber directly from the database on the fly.  I've been able to do that, but it's not fast enough.  I'm sure there's a way to do that quickly.  But that's why I'm using a csv file for now, which is fast.

I was wondering if maybe OSC would allow sending patch name and library instead of rownumber.  Then there'd be no need to retrieve anything from the database.

@thsve 

Hi.  I like your program.  While I've got 2 hands on my keyboards playing, I need to be able to quickly change patches.  And moving a mouse around on a small portion of the screen doesn't work for me.  That's why I've gone full screen with my AHK version.  Also, there's another thing I haven't mentioned I'm about to add so I can play music and make patch changes on the fly, with little interruptions.  Using AHK, I dual purpose my computer keyboard to quickly send specific program changes to Unify.  For instance, if I hit Q key, it will send a particular patch to a Unify layer - and likewise with other keys.  So, it's the personal customization that I get from AHK that let's me do things that probably no one else wants.  

@craigr68 

I can see that my program in the current state isn’t optimal for live playing. Even if I have set up some shortcuts, it is heavily relaying on the mouse. I also have included a personal, experimental and highly unsupported feature, the possibility to set and filter rating from 1 to 5🤗.

Publishing source code isn't urgent. This discussion of key features and work-flow is much more important.

I have also been working on a Unify remote-control program as a very back-burner project, so I'm keen to hear from users what features are most important for them, especially for live play, where as @craigr68 points out, both hands are already busy on the MIDI keyboard(s).

Now that I finally got most of the bugs ironed out, it occurred to me that I really haven't explained what my script ultimate goal is.  I did explain I use 2 midi controller kybds.  With the script I can left click to send any Unify patch to the DX, and right click to send any patch to the M-Audio kybd - independent of each other using Unify Standalone (thanks to the new OSC features).  And that's good for comparing and customizing patches, setting sound levels, testing patch combinations, etc.

But there's more.  In the few years I've been into VSTs, I always wished I could switch programs like you can on a hardware synth.  You know, those program switch banks you had on Memorymoogs, Oberheims, DXs, etc.  Although modern midi controllers have sliders, knobs, and pads, they don't have switch banks like that.  That's why I came up with another feature with this script.  I now have it where I dual purpose my computer kybd as those switches.  After all, I don't really do anything with my computer kybd while I'm playing.  The screenshot shows how I have certain patches assigned to keys.  It might be nice to repurpose a hardware device like an Ableton push or something, but this will suffice.

Did I answer the work flow question?  If not, do you have an example of what that is?  Things come to mind like flowcharts, pseudocode, or gui screenshots, etc.

Posted by: @craigr68

Did I answer the work flow question?  If not, do you have an example of what that is?  Things come to mind like flowcharts, pseudocode, or gui screenshots, etc.

Yes, I'd say you've covered it nicely. So you use two separate MIDI keyboards, and with the recent OSC changes in Unify, you can now assign each keyboard to its own layer in the Unify stand-alone app. You have also added some features to quickly load patches into each layer.

Your idea of using this to compare patches is very interesting. This had not occurred to me before, but I agree it could be very useful.

@getdunne 

Is there an OSC command for "DELETE Layer" implemented?

Posted by: @thsve

Is there an OSC command for "DELETE Layer" implemented?

Not yet, sorry.