Results 1 to 7 of 7

Thread: Osculator + SooperLooper + TouchOSC

  1. #1


    Hello,

    I just started with Osculator in the past week. I am using Osculator to bridge the gap between SooperLooper and TouchOSC. I have the basic functionality working (record, overdub etc . . ). I have run across a couple of questions that I can't seem to get around. The first is, I want to trigger SooperLooper's 'substitute' mode, the osc looks like this: /sl/0/down substitute (http://www.essej.net/sooperlooper/doc_osc.html). When I try to remap the TouchOSC input to trigger this, something in Osculator mucks up the word substitute. I have uploaded an image to illustrate:



    Why?


    My second question is regarding routing to the 'feedback' or 'input_gain' parameters in SoooperLooper. I can't seem to figure out how to route those with Osculator. The SL manual says it wants input like this: /sl/#/set s:control f:value, where value is a float 0-1. For feedback I put:



    Any thoughts on what am I doing wrong? I have also tried with: 'f:arg[0]' instead of 'all args'

    Any suggestions are greatly appreciated.


  2. #2


    Hi mrfs,


    The first screenshot a bug in the actual build that deals with OSC strings.

    I will release the fix as soon as I have a bit more things to include.

    In the meantime, I have sent you a build that fixes that problem.


    For the second issue, it seems the definition of your message should include the control name as a string (like you did in the first example). So I suggest you remove the <all args> argument, type the control name as a static string token (just type the letter and confirm by typing space), and add a f:arg[0] argument.


    The f:arg[0] will be replaced as a float with the first argument of the input message. If your input message only has one argument, this is equivalent to <all args>.


    Best Regards,

    Camille


  3. #3


    Hi Cam and mrfs,

    I am also trying to use Osculator to bridge between TouchOSC and SL...

    With the info above I was able to get routings happening with commands like the first screenshot, Record, Undo_all, etc.

    Cam could you post a screenshot of what you are saying to do in the second case above that involves an integer value control?

    For instance what would the Edit rewrite address window look like exactly for the SL command

    /sl/0/set/ feedback ??

    Thanks so much,

    AL


  4. #4


    Hi Al,


    Here is what I think it should look like :





    As you can see in the screenshot, the target address is "/sl/0/set", the first argument is "feedback" (type it without the quotes and press space to confirm the token), and I added an "argument at index" which I changed to type float using the drop down menu attached to the token.


    Best,

    Cam


  5. #5


    Hey Cam,

    thanks for holding my hand in this.

    I did get the float OSC messages to control sliders in Sooperlooper!

    I was so excited to get anything to communicate with Sl in OSC!


    I do have a question now regarding using Sl's OSC registering commands back through OSC(there is a new command line utility that tells SL to register commands for parameter feedback to a user specified OSC port)

    I did get OSC param feedback back to Osculator but the OSC addresses from SL seem to get lumped together under one Osculator message kinda.

    Thanks so much

    AL


  6. #6

    Lightbulb

    You are right, this is the problem with the different protocols existing in the OSC world.

    There is exactly the same kind of problem with the TUIO protocol which uses different 'selector' values at the same argument index. Since TUIO is fairly popular I've included some kind of translator making it easy to use. Maybe I should take a look a SL and see what I can do.

    However, there are simple things you can do already.

    First, take a look at the messages by inspecting their content.
    To do this, bind a Console Log event to /sl/global for example, or /sl/0/ctrl.
    Open the Console Log, and have a look at OSCulator output.
    Identify the argument that is changing.

    Now, OSCulator has a command to "unfold" message based on an argument index. Select the argument (the line corresponding to 0, 1 or 2 in the list) and do Edit->Demux. If you know what demultiplexing is, then I think it will be fairly easy to you to understand what's happening.

    If you don't know, here is what happens.
    Take the example of MIDI Notes, since this is exactly what happens when you send MIDI Notes to oscltr.
    Some notes are received, following OSC message are internally generated :

    Code:
    /midi/note/1 41 64 1
    /midi/note/1 41 0 0
    /midi/note/1 43 32 1
    /midi/note/1 40 89 1
    /midi/note/1 40 0 0
    /midi/note/1 43 0 0
    /midi/note/XXX arguments are pitch, velocity, triger.

    We have that a note with pitch 41 has been played at velocity 64, then note 43 and 40 simultaneously, then the notes where released.
    In OSCulator here is how it looks :

    s1.png

    if you select the first argument (pitch), and do Edit->Demux, new messages will appear, based on their first argument.
    Here is how it looks now :

    demux.png

    As you can see, now you can do something with those message, because the pitch argument is now made visible as a virtual message.
    I hope it makes sense, and that you will be able to use that feature with SL.

    Best,
    Cam
    Last edited by camille; 01-17-2011 at 10:45 AM.

  7. #7


    HI Cam,

    yes that explanation and Demultiplexing the OSC from SooperLooper helped as I now have some of the SL OSC arguments showing up as their parameter names in Osculator... Big fun... "Look Mom no hands"


    The demuxed arguments for 'Record' coming back from SL are confusing as the argument Record is not part of the group... like say the pan_1 arg is.

    I figure that initiating Record in SooperLooper is dependent and conditional...here is what comes back from Record:[img][URL=http://img443.imageshack.us/i/[/img]


    where this is more intuitive:[img][/img]


    I guess that the State of California's money problems and the effect on OSC.org's funding

    is one big hurdle in the progress and standardization of the OSC spec.

    Thank you very much for OSCULATOR as without it a whole lot less would be possible in the brave new world of OSC!


    This sort of challenge(getting OSC going) is fascinating to me, but as a professional musician I do appreciate your Osculator and help, Camille, as without it my progress would cease, PERIOD!

    I did cop MaxForLive and that's a 'Headful of new issues' ... eventually I hope to be more inside this sort of 'argument with my computer'... but in the mean time I have to also play for a living too.

    Anyway,

    Thanks,

    AL


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •