looopy (max version) BETA testers?

  • I am getting dangerously close to having a beta version of loopy (see info on pd version @ http://docs.monome.org/doku.php?id=app:loopy) that runs in MAX - to be called "looopy."

    Functionality is similar to the original pd version: a sample player combining a large sample bank and multiple trigger modes - momentary, one-shot, loop - with flexible recorders and simple mlr-like sample cutting. Each row can be defined independently to function like a multi-sample one shot player or a bank from which to choose a sample to be sliced.

    This Max version has a few features that should make this easier to use:
    - drag and drop sample loading
    - better save and recall of sets
    - better global controls for row & sample settings
    - quantization to the individual sample level

    I am looking for a few beta testers to give looopy a spin, and help me find bugs or make suggestions to get this ready for general release. Interested?

    Note that my current version of looopy runs with monome/arduinome serial. As I am on win 7 with an Arduinome, I do not have a working version of SerialOSC to develop/test with.

  • I'm down. win7, jan2011 edition 64

  • willcarter - do you use monomeserial?

  • well, I use whatever the patch is made with, but I prefer to use serialosc

  • i can test on osx, monomeserial and my gs64 or 256.

  • I can test osx, arduinomeserial, macbook pro 2008 edition 2 gig ram, 2 gHz processor. I really wanted to use loopy PD, but I had issues with it lagging hardcore on my system (like being slow to button presses etc) so I am looking forwards to this test. I can also test on an older windows machine if you would like (1ghz, 512 ram).

  • I'm interested. I'm on osx, monomeserial, old 128

  • I'm in. same as above

  • I'd like to give it a go. MBP i7 quad-core, gs128 OSX 10.6, monomeserial.

  • Awesome, 6 testers: willcarter, pororoca, n8bit, Eimhin, i.morgendoerfer, CheeseNoOnions

    Please send me your email to bongo at cosmiccasbah dot com. I should have a test version of looopy to you this weekend.

  • i just sent looopy V0.5 beta to willcarter, pororoca, Eimhin and i.morgendoerfer. i have not received an emal addy for n8bit or CheeseNoOnions.

  • no buttons responses
    the preset management seems to work well

    i5/osx 10.6.8/4 Go Ram


  • try with the prefix loopy than it should work.

  • now it works with prefix loopy instead of looopy

    the preset management has some issue : it does not load all the samples each time

    i keep on testing...


  • oops, sorry about the prefix issue. i changed it on screen to looopy, but not in the code (which still has loopy from the old pd version). i'll fix this - and other things folks find today - in a quick release tonight or tomorrow.

    i.morgendoerfer - preset seems to load all my samples ok. are you sure you hit the 'set' button for a song slot after you initially loaded all of your samples? if so, please provide me some more detail about your seuqence of steps to try to set/recall presets and i'll help to debug.

    Cheese & Dean - app on the way shortly (with the prefix thing fixed to 'looopy')...

  • have no issues with the preset management.
    tried both versions 64/128h on my 64/256.
    i am scratching the surface, but looopy is super stable and i like the intuitive gui.
    great work, bongo!

  • I'm looking forward to seeing how the GUI has improved.

  • app sent to you egon77.

    one of our testers reports an issue with led's not lighting correctly. single or cue mode, in some rows led's are not lighting on the right side to show progress thru the sample. he also reports saved song presets not reloading all samples. i do not have the same issues. anyone else experience these bugs?

  • no problems with saved song presets and not lighting led's.
    maybe the led's in the cue mode are confusing, because they start on the sample player's column and not on the first.

    row mode: hitting 2 buttons simultaneously is not working.

  • i am at home with monome now, and led's are behaving the way i expect them to, depending on row mode:

    MULTI mode - led's light up on both left and right sides for any sample currently playing

    SINGLE mode - led lights up on left side for single sample playing; led's progress across right side (a la mlr) to show progress in currently playing sample

    CUE mode - led lights up on left side for currently playing sample; another sample can be queued on the left by tapping that button; the queued sample led should blink. led's on the right progress to show position in the currently playing sample. a queued sample will start playing when a button on the right is pressed, so you can start from any of 8 positions within the sample.

  • pororoca - i'm confused by your comment "row mode: hitting two buttons simultaneously is not working." are you trying to play a subloop (for example to loop between positions 2 and 5 for a given sample)? or are you trying to play two samples at once? you can only play two samples in a given row if the row mode is MULTI.

    sublooping is accomplished in SINGLE or CUE row mode by pushing and holding one button on the right side, then pushing another on the right side. for example, pushing and holding the 2nd button on the right side, then pushing the 5th button will cause the sample to "sublooop" between these two positions. FOR SOME BONUS FUN, TRY PUSHING & HOLDING A BUTTON WAY TO THE RIGHT, THEN PUSH ANOTHER BUTTON TO THE LEFT OF THIS. YOU WILL GET A SUBLOOP PLAYING IN REVERSE!!

  • sorry for confusion ;) i am austrian.

    when row mode is set to multi, try starting 2 loops at the same time.. it don't work for me. when i hit a bit delayed it works and i clan play all 8 samples in multi mode.

    edit: sub loop and reverse is fun ;)

  • pororoca - my father's family is originally from vienna, though i have never visited.

    now i understand your problem. i will test this once i am home from work tonight. this may be a design flaw...

  • hi!

    i had leds issues on the right side of my 128 on single and cue modes. it does not display the leds movements with the built-in coreaudio (osx 10.6.8)
    but it works with soundflower and ableton.

    and it's an very cool app!

    Edit: it would be cool if the sub-loops were preserved when you change the samples in single/loop mode :)


  • @bongo I just emailed you to test.

  • everyone who has asked to test looopy should have received the second beta version: V0.6, which fixed a couple of critical issues identified by some of you.

    i.morgendoerfer is still having an issue with right side led's not working correctly no matter what audio drivers he uses. anyone else having probelms with led's on the right side?

    i am still looking at some issues concerning the recorders, but i would like to make a general release of looopy within the next week. it would be great if those of you beta testing this can give looopy some additional testing over the next few days if possible.

    and is there anyone out there who cares to work (with me or one their own?) to make a good demonstration video using looopy?

  • ^ kinda late to the party but i'd like to help out if I still can, with testing or demo video or both...this sounds like a bitchin patch!

  • ringo wong - just sent.

  • hey bongo, I'm on a mac with an arduinome here, if you want to get that slice of demographic use.

  • i too am experiencing the late one step sometimes w/ the pattern recorders as well as the double hit in the beginning sometimes. it sounds good when i am recording the button presses, but then on playback some of the notes are late, some are on time. also, i'm not 100% certain but sometimes i think i was noticing the playback of the pattern recorders changing over time. i had a few loops and drum hits going in time, and then all of sudden one of the recorders was off/hitting a step late when it wasn't doin taht before.

    i'm on a macbook pro running 10.6.8
    using a walnut 64, max 5 runtime, and monomeserial

    this app has great potential!

  • thanks ringo wong. i will be digging into the recorders to figure this out. stay tuned...

  • OOOPS!

    the bug came from me : i did not uncheck the "In Audio Interrupt" boxe in the DSP window.

    My mistake. Sorry


  • i made some good progress this morning figuring out timing problems with recorders, but time to head to work. i should have a new version for testing within the next couple of days.

  • emailed you, sounds like fun! Osx, Arduinome 128 and serial osc.


  • I'd like to get in on this as well if possible.

    -MacBook Pro OSX 10.6.8
    -40h (x2)

  • @talks - email me bongo at cosmiccasbah dot com

  • I'm also getting issues where the right side is showing the lighting from the left hand side. Slicing is working as expected on the right but the lighting is wrong.

    arduinome 128, serialosc, monomeserial max patch OSX 10.6.8, Max 5.1.9.

    Let me know if there is any more info I can provide, the app is really fun already!
    nice work

  • hi dylan,

    as i am on arduinome & windows, i cannot yet test with serialosc or serialosc/monomeserial combo.

    let's start with the basics:
    - i am familiar with arduinomeserial, not serialosc. in arduinomeserial, my 128 is setup with two logic boards, the second with a column offset of 8. is this set correctly for you? (sorry for asking the obvious, but i just want to be sure)
    - in looopy, are you set to 128H for your monome?
    - each row in looopy can be set to multi, single or cue mode. in multi mode the left and the right are intended to show the same thing: currently playing samples; a button push on either side starts/stops the sample. in single and cue modes the left side shows the chosen sample, the right side should show sample progress; right side button push should slice the sample.

    next, i wonder if you are having a problem like i.morgendoerfer - see above. he was having an issue with his audio settings.

    beyond that, as it is working fine for me (and others) who are using arduinomeserial or monomeserial directly, i wonder if it is an issue related to serialosc and monomeserial max patch. this may well be a bug in my code that has not turned up until now. and i certainly want to get this working with serialosc.

    after checking the items i list above, let me know if you are still having the problem. if so, perhaps you and i can use the monome chat room to do some real-time debugging. i would likely send you a test version of looopy that outputs led messages to the max window so we can see what is going on.


  • Hey Bongo,

    Thanks for the response. The app is working as intended from a button press point of view it's just that the lighting on the right side is showing what's happening on the left so when I'm slicing something up it just shows a single light for the sample that is playing on the left.

    My Arudinome is running custom firmware and works as a monome 128 so doesn't have any column offset. It works as a normal monome 128 in serialosc and works ok as a 128 with MLRV and polygome.

    Loopy is set to 128h mode.

    I'm in single/slice mode for the entire top row.

    I've tried both audio settings as per i.morgendoerfer's settings and it is the same in both cases. Also to be sure I ran Max, opened Loopy and reproduced the crazy lighting and then ran MLRV directly afterwards to make sure it wasn't something weird with serialosc or the monomeserial max patch I'm using. MLRv worked as expected.

    If you want me to run a debug build or post some messages from the max window let me know. I'm in New Zealand so my time zone is way out for most of the world. Also my wife is away this weekend and I have to two kids, that either means lots of monome time or none, I'm not sure yet =)

    Nice work so far anyway, keep it! It's apps like this that inspire me to learn Max properly.

  • If I open up the monome sub patch and print what is being sent to udpsend I never get an led messages for the right side, all the led messages are like
    /looopy/led_row 1 2 0 or 1 1 0

    If I switch monome sizes I get a big dump of /looopy/led messages ranging up to things like 15 7 0

    If I print what I'm getting at udpreceive I'm definitely getting messages like /looopy/press 13 1 0

    hope that helps.

  • hi dylan,

    the message we care about here is the led_row message. i just ran a test where i played a sample in row 2, column 0 (1st column, as they are numbered 0-7). here's the start of what is being output to udpsend:

    /looopy/led_row 2 1 1
    /looopy/led_row 2 1 2
    /looopy/led_row 2 1 4
    /looopy/led_row 2 1 8

    the first digit is the row #
    the second and third digits are left and right side of the monome, and are a binary bit map:
    1 means light the first led (0 0 0 0 0 0 0 1)
    2 means light the second led (0 0 0 0 0 0 1 0)
    4 means light the third led (0 0 0 0 0 1 0 0)

    we don't see it in this example, but
    7 means light the 1st, 2nd and 3rd led's (0 0 0 0 0 1 1 1)

    i am not sure why you are not seeing a similar sequence of output to udpsend. can you email me screen shots of your main looopy screen, and the output you are printing to show what is being send to udpsend? bongo at cosmiccasbah dot com

  • Hey Bongo,

    i've recorded some data for you and I'll email it through, hope it helps!