MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Programming the grid
MUFF WIGGLER Forum Index -> nw2s  
Author Programming the grid
a scanner darkly
Starting a thread for a more technical discussion on programming Monome grids.

Will update this post with useful links as they get added.

Monome protocol description:
http://monome.org/docs/tech:serial
a scanner darkly
Made some progress yesterday with a simple sketch that turns on a button LED when the button is pressed and turns it off when the button is released.

Basically just calling setLED from buttonPressed and clearLED from buttonReleased. I forgot to add a delay in the main loop, without it the event handlers for buttons weren't getting called sometimes (verified with the serial monitor), adding a 5 ms delay to each event handler and the main loop worked really well, I tried to get to replicate hang buttons but everything worked well and seemed responsive. I suppose I just need a delay in the main loop, no need to add it in the event handlers.
scottwilson
Cool. Thanks for setting up the thread.

Once you get the button press responses working, it's pretty straightforward from there.

As a later step, you will see that if you want to update more than one at a time, you can just update the memory matrix directly and then call refreshGrid(). This is good for automata type devices.

Also, the page (first) dimension of the memory matrix is useful for paged displays like the straight sequencers I made, but you can easily hardcode it to 0 for things like the otogrid that don't need the paging.

Also, I'm currently working on allowing the setLed to allow a number from 0-15 in the case where you want to set brightness on devices that support it. May be a little bit - code is in progress. Expect it mid next week hopefully.

-s
a scanner darkly
Yep, that's exactly what I've been doing for my sketch (which is an implementation of Conway's Game of Life), updating the memory matrix directly and then calling refreshGrid(). I'm just hardcoding page 0 for now, but it's good to have pages available in the base class.

I assumed varibrightness already worked since setLED() accepts the value parameter and thought I had some issues with my sketch since all LEDs were either off or fully on - didn't look into it until this morning and just saw that implementation for varibright == true is empty :-) I might give it a quick try once I get the simple version working, looks like should be easy enough to add.

In any case varibrightness is more of an eye candy right now, but once it's implemented I'll do a variation on Game of Life where each cell can have 16 states instead of 2 and the rules are updated so that each cell can become more or less alive instead of just on/off. I tried this "fuzzy" variation using floats for cell states a loooong time ago, had to tweak the rules a bit but it worked quite well. Translating it into voltage might create interesting stepped voltages that influence each other.

And after that I'm going to use the inputs to influence the rules, so it will essentially become a voltage controlled Game of Life :-) And some way to use the digital inputs to inject new cells (and, of course, new cells can always be created by simply pushing the buttons).

Question about delays - I see that refreshGrid already does delay(5), but I still needed to add another delay in the main loop as well as in the button event handlers before I got event handlers to reliably execute - is it because 5ms is not sufficient? Do I even need a delay in the event handlers (they should probably execute as fast as possible?), or just in the main loop?
numan7
w00t once my recently ordered nw2s::b arrives I want to try coding up a very extensive matrix-mixing sketch that uses a monome grid to control (digital) mixing of the b's analog inputs into its analog outputs, and (simulateously) control the i/o routing of a 4ms vcam (euroack module) by muting/un-muting the vcam control-inputs patched from the the b's digitial outs (controlled from the grid).

i think i'll call it something like SuperMat...

cheers
a scanner darkly
I think using analog ins/outs on the ::b itself won't work on audio (Due wouldn't be fast enough to sample 12 analog inputs at a rate that would be sufficient) but should work for CV. I might be wrong though.

But yeah, the VCAM is a good partner for the ::b since you can control each VCA individually, and great idea on using a grid to control all of that!

One application I see is simply using the grid instead of mute buttons for VCAM but so that instead of on/off the ::b would slew it (you would have to use the analog outs, not the digital outs) to avoid clicks when using VCAM for audio. Of course, this could then be expanded to having pages / VCing or sequencing presets / storing presets on SD.
scottwilson
[edit] Just checked in some varibright code that's at least working for the first quadrant. Some weird stuff going on still, but it's getting there.

Interesting stuff here - I'm just jumping in to say that I have code for varibright support, but need to test a bit before checking it in... will let you know.

s
a scanner darkly
Almost got my Game of Life sketch working, it's funny how unforgiving C/++ is after many years of Java/C# :-)

Tripping on little things, like having to define methods in specific order - forgot about that! Time to read K&R and Stroustrup again - which is what I'll have to do this weekend instead of programming the ::b as I'll be travelling.

I do want to put this thought here before I leave though... :-)

Grid and User Defined Waveform Oscillator
or
Grid and Harmonic Oscillator

w00t

I guess I should also read up on interpolation...
a scanner darkly
Just saw your edit - haven't had the chance to try the new VB code yet, will report once I do!
scottwilson
VB code is in there now for the probability trigger sequencer. I had to add another 5ms delay - I guess to keep from overloading the monome buffer, but there's still a tad bit of ghosting, so I may still be cramming too much down the pipe.

It'll do for now until I get to spend some time to kill some other bugs along with this one.

s
a scanner darkly
Interesting, so is the USB code synchronous or asynchronous? Does it wait for the grid response when sending data? I'm curious on why adding delays help, sounds like it gives the grid the time to catch up?

I did run into some weird timing issues yesterday, the sketch would freeze for a few seconds here and there (you could see the red beat LED getting "stuck" when that happened too if I remember correctly) but my code was buggy anyway so I didn't mention it. I did add some delays here and there, I thought maybe I wasn't giving enough CPU to interrupt handlers or something like that, and it did help.
scottwilson
Yeah, not sure about the weirdness with the monome. I had been having issues even with the grayscale, but I fixed it by using a frame command rather than successive individual updates, so I figured that I was overloading the monome's CPU.

It seems to be better now, just giving a couple of milliseconds here and there to let it catch up. I could probably follow up on the monome board and get some insight from some of the app developers to see what they think.

The USB code is not synchronous - the good thing about microcontrollers with on-board USB is that they have dedicated circuitry for it. So at the lowest level it's async, as well as the app level, the monome never sends an ack back when you send it data and forget it.

Looking forward to seeing your code. Lemme know if you get hung up on anything.

s
a scanner darkly
Thanks Scott, will do - so far it's just the lack of enough knowledge on my part about the underlying architecture but things are becoming clearer, and other than a couple of very minor frustrations it's been a surprisingly smooth sailing. The more time I spend with it the easier it gets, and the easier it gets the more exciting it becomes, I was literally fixing bugs at the last minute at the risk of being late for my train!

With the Monome it sounds like maybe it could have its own queue and a handler so that the main sketch could throw things at it and it would process them at a speed the monome itself is comfortable with. So, refreshGrid would run on its own clock outputting whatever is in the cells, and if it's behind it wouldn't matter.

This is all speculation, I need to look at how the clocks actually work :-)
MUFF WIGGLER Forum Index -> nw2s  
Page 1 of 1
Powered by phpBB © phpBB Group