lagging lights when using 2 units *Fixed!* - New Problem!

  • Problem Fixed!

    Upgrading to the latest version of MonomeSerial seemed to fix the lagging lights problem...

    But introduced another one! See post below!

    -----------------------------------------------------------------

    when using 2 units at once within aes mlr, a 40h and 128, i get lagging lights when running lots of tracks and doing lots of button presses... almost as if the monomes cant keep up...

    is this usual?

    the sound is fine - all the samples trigger off fine - just the leds cant seem to follow fast enough...

    any suggestions? (both units are hooked up via a powered hub)

  • do you have a cpu meter running?

  • nope - no cpu meter running, also running on a nlite'd XP install.

    when i use them separately - they work great, very responsive, no lag at all!

    together - not so great...

  • try running a cpu meter and see if you're getting any spiking with two units.

    if not, it could be something weird with the baud rate that monomeserial is setting (a bug, in other words)

  • so i upgraded to the most recent version of monomeserial, and it fixed the problem!

    :D

    but introduced another one!

    :(

    now when offsetting the rows in monomeserial for my 128 to appear below my 40h - the unit skips a couple rows (they no longer work!).

    for example (40h is rows 1-8, 128 is rows 9-16) using row offset of 8:

    row 11 and row 16 no longer work.

    when i change the row offset in ms the non-working rows move up or down accordingly...

    I've only tested this with aes mlr 256...

  • does it do the same thing with the test patch?

    which monomeserial version? (i.e. which platform?)

  • monomeserial 0.2.1.2a and now that i ran the test patch - all rows seem to function fine...

    so i guess it's an issue with aes mlr?

    *sorry - yeah XP!

  • that's xp, right?

    might be an issue with the row protocol.

    iirc, mlr uses led_row messages for playback rows