Open Sound Control (OSC) is here

Post Reply New Topic
RELATED
PRODUCTS

Post

NKirn93 wrote: Mon Sep 14, 2020 11:04 am
moss wrote: Mon Sep 14, 2020 9:46 am There are 64 user parameter, therefore you cannot go higher. E.g. if you want to use the first 2, you should do, e.g.:
/user/1/value 80
/user/2/value 55
Sure, but if I said that an XY pad should have the address /user/50, why would that address then increase every time I switch the banks in user mode? The faders are the ones who should have their address number increase as they have /@.{parent.variables.n} in the address bar, not the XY pad where the address number is fixed. Right?
Ups, sorry, I was writing nonsense. User parameters are also paged and therefore valid numbers are only 1 to 8: /user/{1-8}/... (see the documentation)

Post

So if I understand correctly, as you switch pages that number increases too, regardless of whether the address is hardcoded to a specific number or not?

Post

NKirn93 wrote: Mon Sep 14, 2020 11:39 am So if I understand correctly, as you switch pages that number increases too, regardless of whether the address is hardcoded to a specific number or not?
No, the addresses are always 1-8. But they address different parameters when you move the page. E.g. if you move to the 2nd page, they address 9-16.

Post

I see. When even when I'm on another tab, the scrolling of banks still messes with the addresses. So I can't use the User mode of your OSC template as-is.
But I can simply create multiple tabs and have faders on them and hardcode them to addresses up to 64, at least it looks like it. As long as I'm no paging through user more banks it should be fine. I'll report back.

Post

NKirn93 wrote: Mon Sep 14, 2020 12:36 pm I see. When even when I'm on another tab, the scrolling of banks still messes with the addresses. So I can't use the User mode of your OSC template as-is.
But I can simply create multiple tabs and have faders on them and hardcode them to addresses up to 64, at least it looks like it. As long as I'm no paging through user more banks it should be fine. I'll report back.
What I forgot to add: you can change the page size of the banks in the OSC settings from 8 to any number between 1-200. This way you should be able to address all at once (but not fully sure if I actually tested it with the user parameters). Note that this will change all bank pages not only user parameters!

Post

OK, after playing around with both Open Stage Control and OSCPilot I've decided to just use both, the former for when working in the production stage and the latter when performing and dubbing the mix. Seems to be the easiest option.

One request though, simply because of how OSCPilot works. Probably unrealistic but still. It would be really handy if the address for user controls was swapped. Instead of /user/n/value you would have /user/value/n. The reason is because OSCPilot automatically appends a number to the end if you use the very hand multi-slider or multi-button objects. This means you get the benefit of being able to move, change the number of sliders, resize and all that. Because that number is in the middle it can't automatically increase it so you'd need to create each slider separately.

If it's unrealistic say so and I'll start bugging them on their forum to add a n+1 or something as a possible solution.

Post

NKirn93 wrote: Mon Sep 14, 2020 4:11 pm OK, after playing around with both Open Stage Control and OSCPilot I've decided to just use both, the former for when working in the production stage and the latter when performing and dubbing the mix. Seems to be the easiest option.

One request though, simply because of how OSCPilot works. Probably unrealistic but still. It would be really handy if the address for user controls was swapped. Instead of /user/n/value you would have /user/value/n. The reason is because OSCPilot automatically appends a number to the end if you use the very hand multi-slider or multi-button objects. This means you get the benefit of being able to move, change the number of sliders, resize and all that. Because that number is in the middle it can't automatically increase it so you'd need to create each slider separately.

If it's unrealistic say so and I'll start bugging them on their forum to add a n+1 or something as a possible solution.
Start buggin them :-)

Post

Now I'm hitting another wall. It seems like there's bidirectional communication on the first 8 User parameters only. I can map a fader in OSC Pilot to a fader in Bitwig and as long as it's between 1-8 the template responds to my movements in Bitwig. As soon as I go to 9 or above that's over. Changing the page size in OSC preferences doesn't make a difference.

Post

NKirn93 wrote: Thu Sep 17, 2020 2:35 pm Now I'm hitting another wall. It seems like there's bidirectional communication on the first 8 User parameters only. I can map a fader in OSC Pilot to a fader in Bitwig and as long as it's between 1-8 the template responds to my movements in Bitwig. As soon as I go to 9 or above that's over. Changing the page size in OSC preferences doesn't make a difference.
Yes, seems I overlooked that the user parameters have no auto-paging and I implemented it myself but forgot to adjust this to the new page size features. Will look into it.

Post

I've hit another wall. Took much longer this time. Is there any reason for the 64 user parameter limitation? I've got this looping template running and I'm hitting up against 64.
Did 64 just seem like a good number or is there a deeper API limitation I'm not aware of?

I'm already offloading as many controls to simple MIDI messages but there are some crucial ones that need both higher precision and bidirectional communication through OSCPilot.

Post

Thanks Jurgen for taking into account the feature request about "duplicate" implementaation for OSC.
To complete my "looping station" it would be great if I could set the length of new clips (already available with other controllers).

Code: Select all

/track/{1-8}/clip/{1-8}/create/<beats> 
/clip/create/<beats> 
i.e. the implementation of the ITrack.createClip (int slotIndex, int lengthInBeats) method, and probably a new ISlot.createEmptyClip (int lengthInBeats).

One more thing in the wishlist ;)
Last edited by giohappy on Sat Mar 27, 2021 11:25 pm, edited 4 times in total.

Post

Apparently /track/1/clip/1/record doesn't create any clip. It just selects the slot. On the other hand /track/1/clip/1/launch correctly creates and launches the clip.
How is the record method meant to be used?

Post

giohappy wrote: Sat Mar 27, 2021 9:01 pm Apparently /track/1/clip/1/record doesn't create any clip. It just selects the slot. On the other hand /track/1/clip/1/launch correctly creates and launches the clip.
How is the record method meant to be used?
Seems playback needs to be active to make it work. So either call /play first or /track/1/clip/1/launch after the record.

Edit: I will change this, so that it will also call launch. Then the behaviour is the same as with session view on the different hardware controllers.

Post

giohappy wrote: Fri Mar 26, 2021 11:23 pm Thanks Jurgen for taking into account the feature request about "duplicate" implementaation for OSC.
To complete my "looping station" it would be great if I could set the length of new clips (already available with other controllers).

Code: Select all

/track/{1-8}/clip/{1-8}/create/<beats> 
/clip/create/<beats> 
i.e. the implementation of the ITrack.createClip (int slotIndex, int lengthInBeats) method, and probably a new ISlot.createEmptyClip (int lengthInBeats).

One more thing in the wishlist ;)
I could have sworn that such a command already exists, seems it does not :-)
Will add it.

Post

I'm probably asking too much now: do you think would sending /track/{1-8}/clip/{1-8}/length and /track/{1-8}/clip/{1-8}/position (fraction of length would be enough) be feasible?

The first would be cheep, while the latter would probably cause too much I/O when the nunber of playing clips becomes relevant. But it would be great for visual feedback on the control surface.

Post Reply

Return to “Controller Scripting”