Multiple-states LEDs, memory and whisky.

Learn about building and using Max for Live devices.
julienb
Posts: 1816
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by julienb » Tue Mar 16, 2010 2:46 pm

bulo wrote:The Launchpad has a "double-buffer" thing, which could be the solution.
Unfortunately, the documentation is a little bit obscur about that.
I'll look at it deeper.
I'm also thinking about the coll solution.
Maschinate, how's going your patch?
I've got almost everything, this playhead feedback is the last and only problem for now.

all proprietary system remains ALWAYS a little bit cryptic!
this is one of the reason I love opensource !
Julien Bayle
____________________________________________________________________________________________________

art + teaching/consulting
ableton certified trainer
____________________________________________________________________________________________________

Machinate
Posts: 11648
Joined: Thu Jun 24, 2004 2:15 pm
Location: Denmark

Re: Multiple-states LEDs, memory and whisky.

Post by Machinate » Sat Mar 20, 2010 10:42 pm

bulo wrote:Maschinate, how's going your patch?
going good, althought I've been too busy with other stuff for a while to do anything new about it, really.

1) got input sorted; button presses go the right places, nice and fast.
2) Got playhead working properly. Basically all I am using the matrixctrl for is the three-state stuff, the data then gets passed to multislider. This gets added to the play position, so I have:
0=not playing, not active
1=not playing, active
2=playing, not active
3=playing, active
Having this sort of arrangement means that I can do this on a list: [vexpr (2*$i1)+$i2], where "$i1" is the playhead, and $i2 is active/not active.
that's then being fed into a last multislider which is the one I output, basically.
3) Sequencer bit is done, too. Switchable from 128th notes to I think 32 bars per step... hehe. End step can be set from 2-64, too.

What I am currently working on is the logic for switching between pages. Unfortunately, when I send a full grid of values to the Launchpad they don't all get drawn at the moment, so I might try some speedlimiting next. That or deferlow, which I know to work with really high loads on the Lemur. Any tips regarding refreshing would really help.

andreas.
mbp 2.66, osx 10.6.8, 8GB ram.

bulo
Posts: 434
Joined: Sat Sep 09, 2006 7:57 pm
Location: France
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by bulo » Sun Mar 21, 2010 12:18 am

What I am currently working on is the logic for switching between pages. Unfortunately, when I send a full grid of values to the Launchpad they don't all get drawn at the moment, so I might try some speedlimiting next. That or deferlow, which I know to work with really high loads on the Lemur. Any tips regarding refreshing would really help.
The problem is more about the Launchpad USB1 built, no?
It takes a maximum of about 1/3 second for a page with every LEDs on. I'm using the patch from the above picture and, personnaly, I can easily deal with this refreshing time.
I didn't get everything about your playhead technique, but I hadn't sleep for about 36 hours, and my brain is full of dust.
You're not using the live.step object, right?
I didn't do anything on my patch for a few days, but as I've said before, I've notice that live.step has one feature that can be a inconvenient: the 1st sequence acts like a master regarding time.
It induces sequences independance limitations (notably regarding the playhead feedback. I can set different loop points for each page/sequence, but I can only access the playhead step count of the first sequence), so I'm thinking about thinking to think about using one multislider (or live.step) per page.
My tongue spits english like a frog and my head is currently searching for a comprehensive language.
And I shit here

julienb
Posts: 1816
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by julienb » Sun Mar 21, 2010 6:22 am

the problem seems to be the link...
it is very strange.

when I mean the link I mean:
- the transmission itself
- the buffer inside the gear
- ?

how could I help with the hardware side ?
Julien Bayle
____________________________________________________________________________________________________

art + teaching/consulting
ableton certified trainer
____________________________________________________________________________________________________

Machinate
Posts: 11648
Joined: Thu Jun 24, 2004 2:15 pm
Location: Denmark

Re: Multiple-states LEDs, memory and whisky.

Post by Machinate » Sun Mar 21, 2010 7:59 am

bulo wrote:
What I am currently working on is the logic for switching between pages. Unfortunately, when I send a full grid of values to the Launchpad they don't all get drawn at the moment, so I might try some speedlimiting next. That or deferlow, which I know to work with really high loads on the Lemur. Any tips regarding refreshing would really help.
The problem is more about the Launchpad USB1 built, no?
absolutely not. USB1 is plenty fast for control data. I think the API is at fault, actually. I remember controlling the Launchpad over midi is a damned sight quicker.
Besides, the Launchpad itself updates REAL fast. I can make it sprint across my sequences at 128th notes without skipping a beat. It must be overloading when I UZI it a stack of shit.

Does anyone remember if there is a way to send the Launchpad a full list of values instead of individual ones?
mbp 2.66, osx 10.6.8, 8GB ram.

julienb
Posts: 1816
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by julienb » Sun Mar 21, 2010 8:10 am

Machinate wrote:
bulo wrote:
What I am currently working on is the logic for switching between pages. Unfortunately, when I send a full grid of values to the Launchpad they don't all get drawn at the moment, so I might try some speedlimiting next. That or deferlow, which I know to work with really high loads on the Lemur. Any tips regarding refreshing would really help.
The problem is more about the Launchpad USB1 built, no?
absolutely not. USB1 is plenty fast for control data. I think the API is at fault, actually. I remember controlling the Launchpad over midi is a damned sight quicker.
Besides, the Launchpad itself updates REAL fast. I can make it sprint across my sequences at 128th notes without skipping a beat. It must be overloading when I UZI it a stack of shit.

Does anyone remember if there is a way to send the Launchpad a full list of values instead of individual ones?

this fu...ng API ... :?
Julien Bayle
____________________________________________________________________________________________________

art + teaching/consulting
ableton certified trainer
____________________________________________________________________________________________________

zalo
Posts: 999
Joined: Sat Jun 27, 2009 9:10 pm

Re: Multiple-states LEDs, memory and whisky.

Post by zalo » Sun Mar 21, 2010 5:51 pm

Machinate wrote:Does anyone remember if there is a way to send the Launchpad a full list of values instead of individual ones?
i think its send it to button matrix

http://www.max4live.info/content/max4li ... ing-values

Machinate
Posts: 11648
Joined: Thu Jun 24, 2004 2:15 pm
Location: Denmark

Re: Multiple-states LEDs, memory and whisky.

Post by Machinate » Sun Mar 21, 2010 7:17 pm

zalo wrote:
Machinate wrote:Does anyone remember if there is a way to send the Launchpad a full list of values instead of individual ones?
i think its send it to button matrix

http://www.max4live.info/content/max4li ... ing-values
yes that works just like I stated before, that's the basics of it, I am asking if there are *other* ways of doing it, like, for instance, sending a full list. That would reduce the number of calls dramatically.
mbp 2.66, osx 10.6.8, 8GB ram.

julienb
Posts: 1816
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by julienb » Sun Mar 21, 2010 7:20 pm

Machinate wrote:
zalo wrote:
Machinate wrote:Does anyone remember if there is a way to send the Launchpad a full list of values instead of individual ones?
i think its send it to button matrix

http://www.max4live.info/content/max4li ... ing-values
yes that works just like I stated before, that's the basics of it, I am asking if there are *other* ways of doing it, like, for instance, sending a full list. That would reduce the number of calls dramatically.
are you sending a full list each time?
is it a polling or a on-event updating?
Julien Bayle
____________________________________________________________________________________________________

art + teaching/consulting
ableton certified trainer
____________________________________________________________________________________________________

Machinate
Posts: 11648
Joined: Thu Jun 24, 2004 2:15 pm
Location: Denmark

Re: Multiple-states LEDs, memory and whisky.

Post by Machinate » Sun Mar 21, 2010 8:59 pm

julienb wrote:are you sending a full list each time?
is it a polling or a on-event updating?
"full list"? I am sending [x y state], as per the API. I am asking whether it is *possible* to send a full list instead, since that would involve fewer API calls.
mbp 2.66, osx 10.6.8, 8GB ram.

julienb
Posts: 1816
Joined: Sat Oct 29, 2005 1:15 pm
Location: France
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by julienb » Sun Mar 21, 2010 9:43 pm

Machinate wrote:
julienb wrote:are you sending a full list each time?
is it a polling or a on-event updating?
"full list"? I am sending [x y state], as per the API. I am asking whether it is *possible* to send a full list instead, since that would involve fewer API calls.
I didn't check/test your patch cause I didn't have a launchpad.
I could apply that to my RGB matrix on the protodeck but it involves too much work and it wouldn't equal your setup


I have several rules here: http://www.julienbayle.net/software/maxmspjitter/
I'm not sure it could help, but about dynamic data, coll could help a lot, as on-event update

try to think about on-event vs polling, storing data in a kind of lookup table vs only use dynamic flow.
if I can help, I'd do
you can use my email (more reliable to catch me)
Julien Bayle
____________________________________________________________________________________________________

art + teaching/consulting
ableton certified trainer
____________________________________________________________________________________________________

zalo
Posts: 999
Joined: Sat Jun 27, 2009 9:10 pm

Re: Multiple-states LEDs, memory and whisky.

Post by zalo » Sun Mar 21, 2010 9:45 pm

Machinate wrote:
zalo wrote:
Machinate wrote:Does anyone remember if there is a way to send the Launchpad a full list of values instead of individual ones?
i think its send it to button matrix

http://www.max4live.info/content/max4li ... ing-values
yes that works just like I stated before, that's the basics of it, I am asking if there are *other* ways of doing it, like, for instance, sending a full list. That would reduce the number of calls dramatically.
i was assuming you could send something like (call send_value 0 0 1 0 1 1 0 2 1....) aka a full list with the message, but i guess this is what happens when you assume

amounra93
Posts: 432
Joined: Sat Jan 24, 2009 8:16 pm
Location: Arcata, CA
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by amounra93 » Sun Mar 21, 2010 10:13 pm

I update the entire 8x8 grid on every step....what resolution are you going for here? That works for me at up to 1/64 resolution, no problem. I don't get any dropout. I haven't looked at your patch, but I read a bit of the posts and it seems like you are doing about the same thing I've done with the tr256 monome patch (I really should get this stuff together so others can use it)...just curious. I AM using js, though. In my experience this is faster. You are welcome to the script I use, its just a nice neat interface to access all the buttons on the LP with simple syntax from the same object. Its pretty easy to use.

I think maybe something else is getting in the way....maybe you are sending some other output to the LP that you are not aware of, and its superceding the first bang its getting from the matrixctl. Just a guess, its happened to me before.

Cheers
http://www.aumhaa.com for Monomod and other m4l goodies.

bulo
Posts: 434
Joined: Sat Sep 09, 2006 7:57 pm
Location: France
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by bulo » Mon Mar 22, 2010 12:09 am

the script I use, its just a nice neat interface to access all the buttons on the LP with simple syntax from the same object. Its pretty easy to use.
That sounds interesting, I'd like to try it!

I update the entire 8x8 grid on every step
I have think about this for a moment but didn't even try because I thought it was nearly the most intensive way for the computer and the LP to do the task.
My tongue spits english like a frog and my head is currently searching for a comprehensive language.
And I shit here

amounra93
Posts: 432
Joined: Sat Jan 24, 2009 8:16 pm
Location: Arcata, CA
Contact:

Re: Multiple-states LEDs, memory and whisky.

Post by amounra93 » Mon Mar 22, 2010 1:11 am

This is the easiest way for me....and it works fine. You just bang the matrixctl every count (whatever the resolution is) and make sure to filter out the stuff that doesn't need to be sent to the LP. I hopefully will have time this week to get all of my monome stuff posted somewhere, but for the meantime, here is the script.

Its been a while since I did all this, so I don't know what pitfalls to tell you to beware of. Basically, it autodetects the first Launchpad instance, and if you feed it (x-coord, y-coord, color) in the first inlet, it will update the launchpad. The second and third inlets are for the top and side rows, the selects the control surface (prolly don't use this, as its unnecessary) and the fifth is to rebuild the api in case things get mucked up somehow. If things don't go right, send a (1) in this inlet.

The outlets give about the same for the first three (key presses), the fourth sends out the active LP mode (i.e. Grid, User1, User2, or Mixer) and the fifth is to let you know when the API has loaded (I can't remember how well this last one works, but I never seem to have issues).

If you haven't worked with js before, its pretty simple: copy the code, create a new object in max (call it [js lpd.js], but without the brackets), then double click on it. It will open a text editor. Paste the contents of the code below into the textedit window, then save it with the filename "lpd.js" somewhere in your max search path. I put all mine into: /Applications/Max5.13/Cycling'74/jsui-library, but I think as long as its in the search path you are in good shape. G'Luck :)

Code: Select all

 autowatch = 1

inlets = 5;
outlets  = 5;
setinletassist(0, "grid input");
setinletassist(1, "control input");
setinletassist(2, "mode input");
setinletassist(3, "control surface assignment");
setinletassist(4, "rebuild api");
setoutletassist(0, "grid output");
setoutletassist(1, "control output");
setoutletassist(2, "mode output");
setoutletassist(3, "active mode");
setoutletassist(4, "api load state");

cs = "0"  
is_loaded="0"
var check = new Task(check_on_api);
check.interval = 2000; 

function check_on_api()
{
    post("check_on_api cs: ", cs, "\n");
    post ("is_loaded", is_loaded, "\n");
    if (is_loaded="0")
    {
        if (cs>"6")
        {
            cs="0";
        }
        api = new LiveAPI(this.patcher, "control_surfaces", cs);
        post("control_surfaces id is: ", api.id, "\n");
        post("control_surfaces type is :", api.type, "\n");
        if (api.type!=("Launchpad"))
        {
            cs=(cs=++cs);
            post("control_surface is not loaded yet, next check control_surfaces: ", cs, "\n");
            outlet(4, 0);              
        }
        else
        {
            post("control_surface has now loaded\n");
            is_loaded="1";
            post ("is_loaded", is_loaded, "\n");
            check.cancel();
            assign_api();
        }
    }      
}

function assign_api()
{
    controls=new Array;
    modes=new Array;
    grid=new LiveAPI(this.patcher, cb_grid, "control_surfaces", cs, "controls", 1);
    grid.property = "value";
    var makecontrols=0;
    for (makecontrols=0;makecontrols<=7;makecontrols++)
    {
        var controlid=(makecontrols+67);
        controls[makecontrols]=new LiveAPI(this.patcher, cb_controls, "control_surfaces", cs, "controls", (controlid));
        controls[makecontrols].property = "value";
    } 
    var makemodes=0;
    for (makemodes=0;makemodes<=7;makemodes++)
    {
        var modeid=(makemodes+75);
        modes[makemodes]=new LiveAPI(this.patcher, cb_modes, "control_surfaces", cs, "controls", (modeid));
        modes[makemodes].property = "value";
    }
    active_mode=new LiveAPI(this.patcher, cb_active_mode, "control_surfaces", cs, "components", 0);
    active_mode.property = "mode_index";
    post("done_building_control_array \n");
    outlet(4, 1);
}

function list(b, v, c)
{
    if (inlet==0)
    {
        //post("receive grid: ", b, v, c, "\n");
        grid.call("send_value", b, v, c);
    }
    else if(inlet==1)
    {
        var b=(b);
        //post("receive controls: ", b, v, "\n");
        controls[b].call("send_value", v); 
    }
    else if(inlet==2)
    {
        //post("receive mode: ", b, v,"\n");
        modes[b].call("send_value", v);
    }
    else if(inlet==3)
    {
        cs=(b);
        post("control_surface_number :", b, "\n"); 
        assign_api();
    }           
    else if(inlet==4)
    {
        if (b==("1"));
        {
            post("control_surface initialize\n");
            assign_api();
        }
    }    
}

function cb_grid(args)
{
    var val=(args);
    if (val[0]==("value"))
    {
        if (val[1]!==("bang"))
        {
            //post("send grid", args[2], args[3], args[1], "\n");
            outlet(0, args[2], args[3], args[1]);
        }
    }
}
function cb_controls(args)
{
    var val=(args);
    if (val[0]==("value"))
    {
        if (val[1]!==("bang"))
        {
            var id1=(parseInt(this.path.slice(28)))-67;
            //post("send control", id1, val[1], "\n");
            outlet(1, id1, val[1]);
        }
    }
}
function cb_modes(args)
{
    var val=(args);
    if (val[0]==("value"))
    {
        if (val[1]!==("bang"))
        {
            var id1=(parseInt(this.path.slice(28)))-75;
            //post("send mode ", id1, val[1], "\n");
            outlet(2, id1, val[1]);
        }
    }
}
function cb_active_mode(args)
{
    if(args[1]>0&&args[1]<3)
    {
        post("active_mode ",  args[1], "\n");
        outlet(3, args[1]);
    }
    else
    {
        post("active_mode 0 \n");
        outlet(3, 0);
    }
}
function loadbang()
{
    check.repeat();
}
http://www.aumhaa.com for Monomod and other m4l goodies.

Post Reply