Page 1 of 1

eight_per_cycle & register_update state

Posted: Fri Mar 11, 2011 6:14 pm
by riwid
Hi

Got osc running with get, set and updates for most things but two things won't work:

1. Sending /set eight_per_cycle 16 don't update the 8th/cycle value to 16. In fact I can't update it to any values.

2. I want to be able to monitor the state of the looper (if it is recording, overdubbing etc) and am sending /sl/0/register_update state url path but I don't get change messages.

Anyone ideas why these won't work?

And I found a misspell in the osc-documentation it says eigth_per_cycle under Global Parameters... I actually tried to send eigth_per_cycle for the set command but it didn't work either.

Best,
Richard

Re: eight_per_cycle & register_update state

Posted: Fri Mar 11, 2011 7:43 pm
by jesse
Ah, that's because the correct spelling is: eighth_per_cycle !

Thanks for finding that typo.

Re: eight_per_cycle & register_update state

Posted: Tue Mar 22, 2011 12:56 pm
by riwid
OK. Got eighth_per_cycle to work. Thanks.

But I am still wondering why I can't register for the Looper's status updates sending the following:

/sl/0/register_update state url path

Is it correct? Is it suppose to work?

Would be very happy to get an answer. I am working on a simple Max for Live GUI for three loopers and also on TouchOSC GUI for iphone and to get the status of the loopers is really crucial. I will make these stuff available if I get that to work.

Best,
Richard

Re: eight_per_cycle & register_update state

Posted: Tue Mar 22, 2011 11:54 pm
by jesse
Have you successfully had any of the server->client callbacks working? For instance, the /sl/0/get commands? If not, start there and we'll try to figure out what is the missing piece in your setup. I'll probably need a copy of your in-development Max setup to really help.

Re: eight_per_cycle & register_update state

Posted: Wed Mar 23, 2011 6:42 pm
by riwid
Got it working using register_auto_update instead :-). Like this:

/sl/0/register_auto_update state 100 url path

I have now a ready m4l device which controls and gets feedback from 3 sl loopers. I am going to test it myself for a while, update it and and will then make it available on this forum.

Re: eight_per_cycle & register_update state

Posted: Wed Aug 07, 2013 3:47 pm
by stuartk
I've run into the same problem. Is there any reason why the state isn't dispatched on register_update?

Re: eight_per_cycle & register_update state

Posted: Wed Aug 07, 2013 5:30 pm
by kasbah
As far as I remember there is something odd about the way SL tracks these states and decides whether it has notified whomever wants to know. It's pretty much a bug. Auto updates are a much safer bet.

Re: eight_per_cycle & register_update state

Posted: Fri Nov 09, 2018 8:29 am
by drumfight
Hello guys,

this is my first post. I registered here in the forum because I'm getting in some trouble with the register_update and register_auto_update command. I red some OSC related posts here that gave me important hints but the register_update makes me headache. Some description:

dump_osc runs on port 9952 and show the right answer of the /sl/0/get state localhost:9952/ localhost:9952/ command sent by send_osc to port 9951 in another terminal. The number is changing correctly when I get state while recording or playing. But /sl/0/register_update state returl retpath AND /sl/0/register_auto_update state returl retpath (with and without timeoption) don't bring anything when I change state (via mouse on GUI or sl/0/hit record).

So I tried the global variant of the commands (without /sl/0) and again no luck. I also testet the /register to be shure that it is all the same but: after adding a loop, the dump_osc showed me the ping answer with the correct loopcount.

I tested on my old laptop running Ubuntu Studio and sooperlooper 1.7.3 (from package) , on a Pi2 running Debian wheezy and sooperlooper 1.7.2 (from package). The target mashine is the 19" computer in our music-setup running KXStudio and sooperlooper 1.7.3 (from package). On all systems I see the same behavior.


I believe that I'm doing something wrong, but now I'm out of ideas. What is wrong here??? I doublechecked the typo, any other idea?

The state is quite important for a OSC->midi feedback (next step is osc2midi) to run the computer headless and see the lightning button on the controller for the loop that is recording. So please help me!!

Olli from OllFe

P.S.: Jesse, thanks for this awesome looper!!! ;)