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

Grid controller for the nw2s::b
MUFF WIGGLER Forum Index -> nw2s  
Author Grid controller for the nw2s::b
scottwilson
Update... here's a sample of it running a trigger sequencer with the 'b as host:



And here's one running a note sequencer on a monome grayscale 64:



In hurry up and wait mode with the 'io module and thinking that the white whale is pretty cool. Not sure I want to add a monome to the assortment, but there is a cool kit at adafruit that's not too dissimilar.

Just got one of these and will be evaluating hooking up via USB or possibly I2C and building a couple of 'b instruments that will use it.

Some days you really wish you didn't have a day job.

https://www.adafruit.com/products/1999

-s
dude
can't speak highly enough about the build and quality of current model 128 monome grid. sure if you want a kit it's another story but damn would i ever buy another new varibright 128 direct from monome if mine was lost/stolen/broken etc. i don't use it all the time but when i do it feels *perfect*
dadek
i'd love to use my monomes etc directly with the nw2s... rater than via ww. thumbs up
scottwilson
Curious how the monome works - I would want an API that basically can query the interface to see if a button is pressed and something that can turn lights on and off - the host should take care of the rest.

The monome is pretty ubiquitous, but not being a performer, I'm not sure I'll be able to justify one anytime soon.

Looks like the place to start would be here:

http://monome.org/docs/tech:ports:arduino

Assuming I can get the UNTZTrument/trellis to run a version of arduinome, and I can code to that API, then you should be able to use the monome just the same. Probably worth going that direction than coming up with something of my own.

Time to start digging through the public code repos...

-s
scottwilson
Whaddya know? There exists code to make the tiles used in the Adafruit kit work as a monome. I think this is using the older 40h protocol, but from the looks of things, they are backwards compatible with the newer, more advanced monome.

https://github.com/rbnstubbs/trellis-monome

Also, the serial protocol is outlined here:

http://monome.org/docs/tech:serial:40h

This is going to be perfectly feasible with a little bit of time!

s
gottberg
iOS 8 now has MIDI over BLE.

A bit off topic, but could this work with the b and a BLE shield (like this one http://redbearlab.com/bleshield/)?
scottwilson
Interesting - It wouldn't work with the shield because if wouldn't allow all of the pins through, but if someone were to make a BLE breakout board, then you could either wire it manually to the SPI pins that the BT breakout uses, or if Adafruit made one that was pin compatible, you could just substitute.

-s
gottberg
b <MIDI over BLE> iPad = Play Him Off, Keyboard Cat.
racs
scottwilson wrote:
Whaddya know? There exists code to make the tiles used in the Adafruit kit work as a monome. I think this is using the older 40h protocol, but from the looks of things, they are backwards compatible with the newer, more advanced monome.

https://github.com/rbnstubbs/trellis-monome

Also, the serial protocol is outlined here:

http://monome.org/docs/tech:serial:40h

This is going to be perfectly feasible with a little bit of time!

s


hey I wrote that code! Glad to see it getting some attention. I should point out before any of you jump on it that it is still not 100% optimized (row/col commands are iffy at best) and it was written before the UNTZtrument, etc., kits existed so it is written for UNO (or any ATMega328) timers. Making the switch to a ATMega32u4 (leonardo) should be fairly straightforward, I think the hardest part would be getting the libraries switched over.
scottwilson
Thanks for getting back. There's also some Adafruit code that's written to be a USB MIDI client... Between what you've got and what they've got, I'll bet it's a matter of glue code.

(And speaking of that USB code, I should make the 'b be able to look like a MIDI device, shouldn't I?)

-s
scottwilson
Getting started...

scottwilson
Making some progress... but quick question if anyone knows: Where is 0,0 on the monome? I am assuming it's bottom left, but in some world, I could see someone making the top left be 0,0.

dude
i thought it was top left
scottwilson
Yes, you're correct - top left. I've gotten it working with the test max files. I'm not a max user, though, so if anyone wants to test it, feel free:

https://github.com/nw2s/trellis-monome/blob/master/sketches/oontzmefir mware128/oontzmefirmware128.ino

In the mean time, it's off to get the nw2s::b operating as host so we can get some cool grid-based instruments running!

s
a scanner darkly
Just wanted to say - very interested in this. To be able to use a Grid directly with nw2s::b will be amazing.

Some questions:

- if nw2s::b can be made to work as a USB host, does it mean it could eventually be used with something like Korg nanokontrol or other generic USB MIDI controllers?

- will it require some additional hardware in order to connect Monome grids / make it a USB host or will it work with the existing USB port?

Thanks Scott, really excited about this development.
scottwilson
I'm studying USB host development right now. Its - oof - a bit daunting, but perfectly doable despite the naysayers I've seen here and there. The client was a piece of cake.

Yes - it will use the second (native) USB host built into the Arduino Due. No additional hardware besides a USB OTG adapter.

I'm guessing that a USB MIDI host would not share much of the same code - to keep things simple in MCU environments, most USB hosts are special purpose - in this case, it would be written to handle the 40h protocol which is extremely simple.

What would be easier would be setting up the 'b as a MIDI device rather than a midi host. Then you could interface it with your computer. We'll see. In my mind, I like keeping those two domains separate and instead building tools that allow you some flexibility, but that is ultimately completely separable of the computer.

s
a scanner darkly
Makes sense. So if I understand correctly, it's fairly easy to make the 'b host a Monome grid via the 40h protocol but making it into a USB MIDI host could be possible but more difficult to implement.

I wonder if all of the generations of Monome devices support the 40h? I'm going to see if I can find this info on the Monome forums.

Either way it will be a great addition to the 'b. I still hope there is a way to connect USB MIDI devices to the 'b - having so many outputs would really benefit from being able to control them with a cheap MIDI controller - this is a much cheaper option than to get a bunch of controller modules instead.

What about using something like Kenton USB host to MIDI to pass MIDI information from a MIDI controller to nw2s::b? Would that work with nw2s::b being a device and not a host?
scottwilson
Sorry - should have been more clear. In general any USB client will be considerably easier than any USB host... and one class of host (storage vs HID vs raw) won't share much code with another class of host due to the way USB works.

The 40h is an older protocol, but it seems like the newer protocols use the same basic principle but with more possibilities. That could mean they are backwards compatible, but once I get it working I'll hunt down a monome to test and see. Modifying to support the newer devices seems like it'd be easy once I got the first one done - as long as I had something to debug with.

I'm not familiar with the Kenton device, so I'd have to evaluate that to answer your question.

-s
a scanner darkly
Thanks Scott, that's how I understood it - easier to make the 'b a USB client than a USB host (and making it a host for different purposes means different implementations).

Since I assumed it would be possible to use a USB MIDI controller with the 'b working as a USB MIDI device by connecting both to a computer which would serve as a USB host and route MIDI messages between the two my thought was to eliminate the computer by using the Kenton device instead. But looking at it again it actually only has one USB port and 2 MIDI DIN ports, so it would only work for MIDI controllers with DIN ports. Here is the link to the Kenton device if you're curious:
http://www.kentonuk.com/products/items/utilities/usb-host.shtml

Still, using my OhmRGB to control sketches or even simply control the outputs on the 'b would be amazing. Same for the monome support, even if it won't work with the newer grids I'll be very much tempted to get a 40h compatible grid just so that I can use it with the nw2s::b!
scottwilson
I'll keep you folks updated. Should be getting the io prototypes next week, so that gives me a bit of a window that I need to shoot. for.
gottberg
The Kenton USB host only works with class compliant midi devices (and then not with all of them).

I don't know if the Monome grid is class compliant, somehow I doubt it.
a scanner darkly
Yeah, I don't think that Monome is class compliant.

I meant using Kenton for connecting class compliant controllers such as Korg nanoKontrol to the 'b.

For instance: the simplest application would be using nanoKontrol to set the voltage of the analog outputs - with kontrol's 8 faders and 8 knobs you could control all 16 analog outs, and then you could use the buttons to control the digital outs. So you get a very cheap controller that lets you control 16CVs and 16 gates. Of course, something far more interesting could be achieved, like same idea but realized as a preset storage.
gottberg
But then how do you connect the Kenton's MIDI out to the b?
gottberg
You'd need something like the iConnect MIDI I think.

[EDIT]

It has both client and host connections as well as 5 pin MIDI
a scanner darkly
Yeah, you would need to use a MIDI controller that has DIN ports in order to use Kenton.

iConnectMIDI should work. Too bad when they replaced it with iConnectMIDI2+ they removed USB host functionality (you can get it with MIDI4 but it's a lot more expensive).
scottwilson
Good news! USB Host code is working (and in the 1.1 branch if anyone is curious). I have the 'b responding to grid key presses and sending out messages to turn on and off the grid positions. Should be able to get a couple of instruments built soon to demo it.

After that, I need to beg/borrow/steal a couple of versions of the monome to test on.

s
a scanner darkly
scottwilson wrote:
After that, I need to beg/borrow/steal a couple of versions of the monome to test on.

s


Email sent!
scottwilson
Just a quick teaser - development is done and I'm working on some instruments. Have a bunch of studio work to do this weekend, so not sure when I can get a full-fledged demo video. This at least demonstrates a small set of interactions with a grid with the nw2s::b acting as host with no computers in the loop at all!

In order to test a number of verisons and sizes, I have acquired a Grayscale 64 as well as a 2012 Varibright 265. This video shows the Adafruit kit running the trigger sequencer.

* From straightforward tactile beat creation to long, evolving trigger sequences.
* Up to 15 trigger outputs, 16 sequence steps, and 16 stored pages of sequences.
* Capable of loading pre-programmed sequences from the on-board SD card slot.
* Internally or externally clocked.
* Resettable, triggered track or page randomization.

[edit] - new link below!

If you have any questions about the Adafruit Oontztrument, ping me. It's a pretty good kit for $100 or $200 depending on what you're looking for. It's certainly not as solid as the monome, but gets you into the club inexpensively.
dadek
very cool, was there supposed to be audio in that video?
scottwilson
No - but there is in this one... I should not be allowed to produce anything similar to music. But it gets the point across hopefully!

https://www.youtube.com/watch?v=wZe22pxMVTI
dadek
cool, thanks. Can't wait to try this out. Guinness ftw!
scottwilson
Not sure why I can't embed videos... the video tag never works for me. Hrm.
nangu
Looks awesome! I have a Varibright 256, and I've been thinking about buying the Monome modules. The lack of a reset input was really bugging me, as well as the fact that half of my grid would be wasted with the current versions. Glad I waited..

scottwilson wrote:
Not sure why I can't embed videos... the video tag never works for me. Hrm.

You just need to delete the 's' in https://

a scanner darkly
That was fast! Exciting news. So many possibilities, I'm thinking this will be also great for more visual feedback from the 'b (and now I want to use my grid as an oscilloscope just for the fun of it...)

So it's probably best to power the grid externally? I've got the ext5v thingy from Monome, I assume that should work when using the grid with the 'b? This one: http://controlvoltage.net/monome-ext5v/dp/1569
scottwilson
It might not hurt, but I don't think it's absolutely necessary. May also depend as much on your rack supply as your monome. The Arduino Due theoretically supports 800mA on the 5V rail, but with a 12V supply, that's a lot of heat to dissipate.

I'll see how the 256 does, but my Oontz 128 does just fine. The monome 64 also seems to do fine, but since it's not officially working yet, I won't count it as an unqualified success yet.

-s
a scanner darkly
Yeah, I think it was mentioned the grid might draw up to 500mA more if it's not powered externally, and my PS is almost maxed out as it is, so it's mostly just to be on the safe side.
a scanner darkly
Quick question - to connect the grid do I need to use a USB OTG adapter specifically or would any Micro B to A cable work?
scottwilson
Good question. I picked up an OTG cable from Amazon cause those were the only cables I could find of the correct persuasion.

It's a Micro B to Female A. Then I use a regular Micro B to male A the rest of the length. I let it poke out through a 2HP gap in my rack.

I'm pretty sure any combination of adapters or wonky cables to get you from one to the other should work.

s
a scanner darkly
Cool, thanks Scott! I wasn't sure if there was something else going on under the hood in those OTG things or if they simply work as a male Micro B to female A adapters. If that's the case I just need to get something to go from a male Micro B to female B as that's what I have on the ext5v thingy I use to power the grid.
scottwilson
I think most of the "OTG" part is built into the device. It was primarily developed so that phones like a Samsung S5 or whatnot can both be a USB client (when hooked to your PC) or a USB host (with the right adapter cable)

Arduino Due is technically OTG capable since that native port can be both client (when hooked to a PC) or host, such as when it's hooked to a monome.

...and speaking of, finally got blinky lights and button presses back on my series 64... screwed the code up somewhere along the way, but fixed it now. Shouldn't be too long before I get this guy working as well as the Adafruit.

s
a scanner darkly
I would be surprised if there is more to it, but couldn't figure out from reading online if the "OTG adapters" was just a marketing term or actually meaning something. In any case it's cheap enough just to test and see if it works, will report back once I try it.
L.C.O.
So, this is very interesting...

I think someone mentioned monome Arc, any chance of interfacing arc?

Or Manta?
a scanner darkly
Or shnth :-)

Seriously, shnth as a controller for the 'b would be amazing. Squishable wavetables, things like that.
djthopa
Following this thread with interest! beer!
myecholalia
^^^^ totally agree. Finally broke down and ordered a nw2s::b because of the upcoming monome integration.
djthopa
Hi,

Maybe i missed the point, but how would the monome be connected to the b?

Would the b have future expansions for connecting a monome?

Thanks!
scottwilson
The arduino as two USB ports on board. One of them is a native micro-B that can be used as a host by using a USB OTG adapter (basically just a micro-B to female A cable). You will need a way to get that out of your rack. I just run the USB cable through a 2HP gap I have anyway.

If there's enough interest in the future, I could make a full-fledged panel that could offer a few connectivity options in a slightly more elegant presentation, but for now I'm concentrating on just the software...

s
djthopa
Thanks for the info Scott.

Hopefully there will be enough interest for a full fledged panel!

Keep us updated with your progress.

Cheers
a scanner darkly
A 2hp expander to bring out the USB ports would be great. There is very little clearance from the Due USB ports on the 'b, definitely would need angled connectors, but then they're pretty close together, so you would need to find one that is angled to the right and one that's angled to the left to use both ports.

The OTG adapter I got sticks out a lot due to its shape, like 2 inches. I was able to get around it by putting the 'b in the lower row, and it's deep enough that the adapter sticking out wasn't touching anything in the upper row.

Another benefit for a panel would be not having to use any special adapters. I didn't get a chance to see if the native USB port would work by just using a combination of regular USB cables instead of USB OTG - it was just easier to use the OTG adapter since you'd need to find a male micro B to female B or A adapter anyway.

It would be great if the cables connecting the expander to the 'b were long enough so that you can place the expander away from the 'b if needed.
scottwilson
Another 2AM type quick demo - this time using the monome GS64 and running a note sequencer instead of a trigger sequencer.

I think the most apparent outcome of this video is that the 64 is a bit small to build interesting sequences directly. The 64 will likely be better suited to some automata algorithms.

Also, it's clear that more entropy is necessary to make this thing act a bit more interesting. Not to worry - that will be coming!



s
a scanner darkly
w00t

Can't wait to give it a try tonight! I was able to successfully connect my grid128 yesterday and did get some buttons lighting up in semi-random manner (and with different brightness level) with one of the grid sketches - probably one of the test sketches? didn't investigate, mainly wanted to test the connection.
scottwilson
Well, that means there won't be any usb issues, but the protocols vary ever so slightly from 40h to series to grids, so that means that the grids won't yet work...

Confusingly, they're close enough that one will make the other do _something_ just probably not what you want it to.

Tho - my grids is on the way... so won't be long.

s
djthopa
This just keeps getting better and better.

Going to have to pull the trigger on this one!
a scanner darkly
scottwilson wrote:
Well, that means there won't be any usb issues, but the protocols vary ever so slightly from 40h to series to grids, so that means that the grids won't yet work...

Confusingly, they're close enough that one will make the other do _something_ just probably not what you want it to.

Tho - my grids is on the way... so won't be long.

s


So VB edition protocol is different from grayscale? I assumed there was one protocol for 40h and another for the later editions but sounds like that's not the case.

Saw your message on the monome forum, let me know if you need help with testing on VB128!
scottwilson
Correct. The protocol is very very optimized. He seems to have made a few optimizations as he went along, ensuring that the most information could be sent in the least number of bits. As the capabilities increased, it took a few more bits here and there.

You can set a complete 40h 128 grid in 32bytes. For series, you can set a full 256 grid in 36 bytes. For VB, you'll need 4 bytes per square, so I expect it will be a bit larger assuming I'm going to be using the varibright feature on most of the programs.

The 256 delivery was attempted today, but no one was home to receive, so I should have it by the weekend!

s
a scanner darkly
Interesting. I'd think for 40h 128 you'd only need 16 bytes (bit per square, 16*8 bits), for series I seem to remember 4 levels of brightness? so 2 bits per square, for 256 that would be 64 bytes, not sure how 36 bytes are achieved, and for VB 16 levels of brightness, so 4 bits per square, not bytes? Anyway, I should really look at the protocols :-) But yeah, that explains what I was seeing.
scottwilson
40H 128 is 32 bytes cause you can only address a single column at a time and the command structure is two bytes (one byte header and one byte payload), so that makes 16 * 2 = 32.

The series and grayscale are actually still only on and off. You can adjust brightness, but only the overall brightness of the board - not individual.

He introduced a 9 byte command that populates an entire quadrant (1 byte for the command and 8 bytes for the 64 bits), and so four nine byte commands = 36 bytes.

I haven't studied the grid structure in detail yet. It's definitely more flexible... The docs are available here:

http://monome.org/docs/tech:serial

Whenever I'm testing commands, I use a tool on OS X called CoolTerm that allows you to send hex bytes over the serial connection. Easy to play with if you're curious.
a scanner darkly
Thanks Scott, this is the context I was missing when I briefly looked at that link before, makes sense. Will try to experiment with my grid this weekend.
djthopa
Well...i bit the bullet! applause
scottwilson
Thanks for the order... a small group going out this week. Only about two or three more that are ready for final assembly if anyone else is thinking about making the plunge.

Can't wait to get 1.1 out to see what everyone does with it!

s
djthopa
Thumbs up for developing this!
scottwilson
@scanner: Grid compatible code checked in. Tested so far with the otogrid. You'll can see the code in there (right now anyway) specifies DEVICE_GRIDS and a 16x16 grid. You'll have to change that to 16x8 if you have a 128.

https://github.com/nw2s/b/blob/b-1.1.0-unstable/sketches/nw2s/bDemoGri dOto/bDemoGridOto.ino

JSON version to come...


s
a scanner darkly
It works! SlayerBadger! w00t

Only had a short time to test it before work, will have more time tonight. At first I wasn't getting anything on the grid (I think I did see "Grid initialized" on the serial monitor at that time but not 100% sure), in any case disconnecting and reconnecting the grid worked. And it's neat that when you do that it correctly reinitializes the grid without having to reset the ::b. So looks like you'll be able to switch the grid between the ::b and the Monome modules easily!

One thing I noticed (which could be by design) - all the buttons work as expected except the top row buttons which just flash briefly with lower brightness when pushed (just the button press, the top row LEDs still display the dots properly).

I'm using the grid with a USB OTG adapter and powering it with the Monome ext5v.

Thanks for adding this - what an amazing addition to what was already a very powerful module! Having more hands on control and ability to visualize things without tying up the outputs means a lot more interesting sketches. Hopefully USB MIDI host functionality will also be added one day ;-)

thumbs up
scottwilson
Glad to hear it! Thanks for the details. I'll check on the top row button presses - certainly not by design. I created a ticket.

I'm not sure the plugging and unplugging is _super_ robust. It's something that I'm working on, but haven't fully tested yet... I know it works to a degree, but in my head I can think of some situations when it is likely not to work.

More instruments and demos coming. I'm also going to try to get some of these that makes sense to work without requiring the grids for visualization/interaction - like the otogrid I wanted to do for a while even before I wrote the USB driver.

s
a scanner darkly
I didn't actually expect hot plugging to work, so that was a nice surprise! But yeah, I can see how it might not always work, and I assume unless a sketch does full grid refresh on each cycle it would need to have some additional code to be executed upon reconnecting the grid. In any case if a sketch is able to save its current state to the SD card then Reset should always work in case something goes wrong after reconnecting the grid.

I'll check on the top row issue again once I get home just to make sure!

Curious now, would HID host code be easier than MIDI host code? I'm thinking of using shnth as a controller for the ::b specifically but might be useful for some other HID stuff - I think Manta is HID? And what about OSC support? This would be the perfect excuse to get a Soundplane :-) And I would imagine there might be people wanting to buy the ::b just to be able to use their Manta or Soundplane with a modular without having to use a computer.
scottwilson
I'm getting a bit more comfortable with the USB code which certainly makes HID and MIDI less daunting, but for now I'd prefer to get the monome users some more depth before moving on.

In addition to the shnth, HID would open up other things like game controllers and other general wackiness...

OSC is certainly worth considering as well, and perhaps easier than either of the other two as I believe it's raw serial... back of my head, certainly.

-s
a scanner darkly
Yeah, I think Monome support is a great first step as it should get more people interested in writing sketches and extending the library, and perhaps somebody else will be able contribute to OSC/MIDI support - wish I could but there is a lot of domain knowledge on both Arduino and USB sides that I would need to catch up on.

I should correct myself re:Soundplane - looks like it uses its own protocol which gets converted to MIDI/OSC by the Soundplane client, but the client code is open source, so should be fairly easy to port by the looks of it.
scottwilson
Soundplane sure is purty. If anyone's got a spare one, I'll code to it as soon as I get it!!

Seriously though, once I get through what I've committed to for 1.1, if there are some other specific models you want support for, I'm happy to try if you can spare one for a while.

There's probably a bit of back and forth I can do with whomever beforehand just to POC it before committing, if you're willing to put some time in and send me some log files.

Some of those devices are rare, some are no longer available, and for others, it's a fairly hefty investment to have around, but could be a fair trade if you can help get started and then do without it for a bit.

-s
a scanner darkly
Thanks Scott - that's a very generous offer, and I might just take you up on this!

I've been tempted by Soundplane for a while now (and did play with one at a synth meet in Seattle) but no support for Windows stopped me so far. Being able to use the ::b might just give me the push to order one. Going to give this some thought...
a scanner darkly
Started a separate thread for more technical discussion on programming the grid, thought it makes sense to keep this thread for more general info / updates.

Link to the new thread: https://www.muffwiggler.com/forum/viewtopic.php?t=124210
a scanner darkly
Finally got my Game of Life sketch working last night. Here is a preview - sorry about the crappy iPad video!

I'll publish the code once I clean it up a bit and add more features (voltage control over the rules and a couple of other things).

So basically it runs the Game of Life using the grid to display it. Pressing a button flips that cell. You'll see me using blinkers in the video (3 cells in a row), they pretty neat in that they are stable by themselves, and add some rhythmic variation.

The top row is also output on the digital outs, and each analog out outputs a sum of all the live cells in each column (so 0 cells == 0V, all 8 cells == max V). The patch is LDB1E drum module, Piston Honda and Braids in meta mode, the digital outs are used to trigger stuff, and the analog outs control everything there is to control. It's really quite incredible to have these many outputs...

djthopa
Yikes!

Excellent work! Cant wait to try this!

Good times w00t w00t
scottwilson
It's so sad when they all die! Having all those outputs is pretty nice.

s
myecholalia
@a scanner darkly: oh....my....god!
please release the game of life patch already as is.
this would be super-nice to have as an additional control interface for an experimental modular gig here in singapore on sunday.
SlayerBadger! screaming goo yo w00t
a scanner darkly
scottwilson wrote:
It's so sad when they all die!


C'est la Vie ;-)

It's a bit weird when you add one cell and it takes a whole colony down! Once I add voltage control over the rules it'll be possible to adjust the rate of birth/death though, so things could be fine tuned, and another option will be enabling probability as well to allow for some chance. One consequence of this is that it will be possible to use some of the outputs to influence the rules, so the game itself will change in non obvious ways. Kinda like a universe circuit bending itself.

I'm also thinking of adding a way to use voltage to create new cells, say a new cell is created when a digital input goes high at the coordinates controlled by two analog inputs.

myecholalia wrote:
please release the game of life patch already as is.
this would be super-nice to have as an additional control interface for an experimental modular gig here in singapore on sunday.


I'll see what I can do, have to do extra hours at work this week while also having to get some things done before I travel this weekend (so, sadly no chance of working more on this until next week) but I'll try to clean up the code and remove whatever was hardcoded for my grid 128. Might have something tomorrow night.

A couple of things - my code depends on the 1.1 firmware so you will need that, have you tried it yet? Also, at this point you can set the tempo with a knob but you can't sync it to external clock yet (Scott - correct me if I'm wrong, I don't think there is a slave clock yet?).
scottwilson
There's no slave clock yet, but I've been adding simpler 1:1 clocking to a few devices... My first demo video shows the GridTriggerSequencer clocked by a 4ms SCM.

Since you based your code on one of the existing grids, you've got the external clocking in what I see of your code (See the comments in timer()). To make use of it, in your ino file, just add something like:

Code:

GameOfLife* grid = GameOfLife::create(...);

// This tells the device that you want to clock it externally
grid->setClockInput(DIGITAL_IN_D0);


// Don't register it with a clock...
// vclock->registerDevice(grid);

// Instead register it directly with the eventmanager
EventManager::registerDevice(grid);


I've offered to add Mr Darkly as a direct contributor to the repo which will make it pretty easy for anyone who wants to use his code who is already using the 1.1 branch and will make it easy to keep his code up to date with the rest of the capabilities I'm adding over time.

-s
myecholalia
don't stress yourself over it.
obviously totally fine if you'd just take your time and finish it first as you originally stated.
just getting carried away with the excitement
hihi thumbs up
a scanner darkly
scottwilson wrote:
There's no slave clock yet, but I've been adding simpler 1:1 clocking to a few devices... My first demo video shows the GridTriggerSequencer clocked by a 4ms SCM.

Since you based your code on one of the existing grids, you've got the external clocking in what I see of your code (See the comments in timer()). To make use of it, in your ino file, just add something like:

Code:

GameOfLife* grid = GameOfLife::create(...);

// This tells the device that you want to clock it externally
grid->setClockInput(DIGITAL_IN_D0);


// Don't register it with a clock...
// vclock->registerDevice(grid);

// Instead register it directly with the eventmanager
EventManager::registerDevice(grid);


I've offered to add Mr Darkly as a direct contributor to the repo which will make it pretty easy for anyone who wants to use his code who is already using the 1.1 branch and will make it easy to keep his code up to date with the rest of the capabilities I'm adding over time.

-s


Had a quick test this morning before work but didn't seem to work - buttonPressed wasn't getting called and it didn't respond to serial input at all. I'll double check again tonight. Here is my code:

Code:

    grid = GameOfLife::create(DEVICE_GRIDS, 16, 8, true);
 
    /* Setup a variable clock */
    // Clock* vclock = VariableClock::create(10, 240, DUE_IN_A00, 16);
    // vclock->registerDevice(grid);
    // EventManager::registerDevice(vclock);

    // This tells the device that you want to clock it externally
    grid->setClockInput(DUE_IN_D0);
    EventManager::registerDevice(grid);
a scanner darkly
myecholalia wrote:
don't stress yourself over it.
obviously totally fine if you'd just take your time and finish it first as you originally stated.
just getting carried away with the excitement
hihi thumbs up


no worries, I was able to clean it up yesterday :-) also it should work with grids of any size now, and I've added a bit of eye candy for the VB grids - cells get dimmer as they get older now (non VB grids continue working as before).

I'll post to GitHub once I have access to the repo.
scottwilson
I'll take a look a bit later. I was over-simplifying a bit, and there may be a little bit more code that needs to be in the timer() function that may have gone missing if you didn't think you needed it at the time. Probably not much tho. Should be quick once I get a chance.

And you have been added to the repo!

s
a scanner darkly
Thanks Scott, I'll take a look as well tonight, could be that I removed some stuff that was necessary when copying from otogrid.

Anybody who wants to give it a try - the Game of Life is on github now! (the 1.1 version).

I've started a separate thread to track progress / issues:
https://www.muffwiggler.com/forum/viewtopic.php?t=124578
numan7



w00t i have installed my b-rig as of last night!

as mentioned previously, my big plan will be to use it, along the Monome Grid, as a 12 x 8 (or 12 x 16 should i decide to break out all 4 VCAMs) matrix mixer for control signals (the Erica Matrices - will be for timbre). i will call this sketch/patch 'SuperMat' (and i think i'll follow a scanner darkly's example, and start a separate thread to track progress issues
djthopa
That is a gorgeous system!

Its Great more people are contributing with more sketches!

I have a 4ms vca too, yes!!
a scanner darkly
Yeah, VCAM is a perfect buddy for the ::b. Actually pretty useful for debugging too, as I find it's easier to tell the voltage judging by the VCAM LEDs as they're not so bright.

Feedback matrix controlled by an automaton is a lot of fun 8_)
scottwilson
Technically, since you're writing code, you can set the brightness factor to whatever you like... The factor is in the PCA9655 driver C file if I remember correctly.

That's one such configuration that would be nice to put into a /configs folder... so folks could customize.

s
a scanner darkly
yeah, i've been meaning to do that. good idea to store it in a config!
MUFF WIGGLER Forum Index -> nw2s  
Page 1 of 4
Powered by phpBB © phpBB Group