lukas412

Wow this looks great! Nice work! Luke

$1 each with free shipping. They are on the way now. I will give an update when I get them. Luke

Awesome! Thanks!

Wow, nice find. Just ordered 150 of these. Luke

Thanks a lot Stryd. I would much rather spend the time programming in my midibox. I'm not to much a fan of max at this point. I want that to do the bare minimum. I mostly want to use this with Reaktor. I'm installing the new programming platform now. The setup tutorials for the tool chain are tremendous. Good work to all of you. I'll start with NRPN's and see how it goes. It works decently well even now, but some apps just kill it. So I think with this optimization it should work quite well. I'm sure I'll have some more questions. Thanks again, Luke

I totally understand what you are saying here, all that I was saying is that its two different protocols. Monome is running on usb2 at 115 baud. So I guess they just don't care if its efficient. There headroom is huge. Try to convert that same system to midi and your gonna hit the ceiling. This is pretty much what I am doing, I think what I would need to do is manage the state of the leds more efficiently, rather than just send out the data whether it needs it or not. For example the way this seems to be working is that it will send out a note off even if the led is already off. It doesn't care. It always updates it whether it needs to or not. So in some ways its simpler to program. You don't really need to store the current state of the led to determine if you need to turn it off or on based on its current state you just send the command anyway. This is the kinda stuff I was looking for! Thanks, I will see what I can do here. Maybe write a c app that can take this in and internally process it so I'm only sending one command to handle an entire row or column, instead of 8. Is that what you are saying? That would really lighten the load. I am not trying to pretend to be an expert. I don't own a real monome and have very limited knowledge of max. All that I have to go on is the fake monome app they have posted. Like I mentioned above, I assume they do it this way because its easy. No true state management. Just fire off the ons or offs, needed or not. If you've got the headroom why make it more complicated to deal with. I could be totally wrong here. Just what I've been able to gather so far. I appreciate your help on this. I hope to make this thing fully work. It's so much fun. Thanks again, Luke

Thanks Stryde. So do you have any recommendations? How would you go about this? I'm doing it exactly like I understand the monome does. I've just added a midi in and out module to the max patch that the monome people supply to test monome apps without having one. I don't want to re-write monome apps just so they will run properly on my hardware. Whether its silly or not this how I understand the monome apps to work. I can see how this is an inefficient way of doing this, but this is how it appears they are doing it. So I would say it is a bandwidth issue, but the monome just has plenty to spare so they writing apps that aren't very efficient to keep the coding simple. /tilted/ its not ains, it works fine even with a lot of monome apps, but some just really pump out data. Thank you. Has anyone else actually created a mb based monome clone, or own one that can give me some advice if I am interpreting this wrong? Thanks all, Luke

Well there is a fake monome app out there that I used as a base for the translation of the midi to osc. When this app is run alone with no midi box there is no bog down. With the Reaktor mlr app for example it will work fine, and then when you get a lot of sequencing going it will start to not respond, and then when you hit stop you can see the midi box continue firing as if its catching up. I think that the way that the monome apps are generally written has a lot to do with it. For example in the reaktor mlr, you have 4 sequence tracks. If you run these straight through no problem. What it lets you do is re-sequence the 8 chops of the loop for up to 8 bars. This can be quantized down to 96th notes. So multiply this times 4 and you can see how its many more than 64 notes going in. Each track is sending out 8 on/offs for every tick from what i can tell. When I look at the watch in max its just pouring out data. The monome will respond to a couple differnt types of commands one of them being the row number then one byte of data eg 0 255. Each bit turning one of the 8 lights on or off. The only thing I could come up with to translate this was to fire 8 note on or offs every time i get the row command from osc. It's clearly an inefficient way to do this, but I'm not skilled enough to clean it up, and the monome has the bandwidth to burn, or it just takes care of that command internally I guess. I mean when this is going on the display on the mb is going nuts, its changing so fast that its just a blur. Maybe I can take a video of it, but I have very little doubt that its a bandwidth issue. Hopefully I'm wrong and one of you guys can help me figure out where the issue is. Thanks for the help, Luke

Just got my knobs, and they are extremely nice. Thanks Neb! Luke

Hello Everyone. So I've built an 8x8 button matrix out of spare parts I had around. I did not use the newer scan matrix code, just wired up buttons and leds the standard old way. I have everything working and I'm running the midio128 application. I've created a max patch to translate the midi note on/off messages into osc so I can run monome apps. This all works for the most part, but I quickly run into bandwidth issues running apps like the Reaktor version of mlr. So I doubt there is much I can do about this, but does anyone have any suggestions for increasing the bandwidth? Some way to run the data through more midi ports? I'm on the list to get the new usb module. Is there some way I can send the data down both midi inputs to double the bandwidth? Is there something other than note on/offs that would be lighter weight? As far as I know monome serial runs at 115200 bits per second, and the midi standard is 31250 bits per second. Thanks for any advice. Luke

Glad to see this is still happening. I wish I could offer some knowledge here, but this is pretty much outta my league, so I hope to learn a lot. Thanks, Luke

I'm gonna get in on these too, just not sure how many yet. Probably about 100 silent buttons and 100 caps. Not sure which ones yet. I'm doubting this, but will ask anyway. Do you think its possible to somehow use a duo led with these? I can see that they only have notches for two leads. Do you think it would be possible to make an additional notch for the third lead? Thanks, Luke

I'm getting really excited for this. I have been wanting a mbseq for a long time now. The pcb looks great thanks for the hard work Wilba. Luke

I think this is the best solution. Stryde for me I simply do not like sequencing midi on a computer. Although I do like to process midi in Reaktor. So for me with the controllers I use it would save me from taking another midi interface with me, but the more I think about it the more I realize that it's a pretty personal/specific use case. So the expansion port is perfect. Luke

Wilba, I know you didn't want this thread to turn into a design committee, but I thought I'd throw this out there. Since there will soon be nice USB modules available would there be enough room to include this in your current design? USB connectivity would be a really nice addition to the sequencer imho. Thanks, Luke edit: also, I would like to be put on the list for two including the enclosure, instead of one.

I also agree. I know how hard it is to put this together (I have started and stopped about 10 times now). So I think your time and effort is totally worth the extra 20 bucks or so it will cost each of us. Luke

I'm in. Thanks! Luke

Got mine today Ultra, thanks they look great! Luke

This is sweet, thanks guys. Luke

I would suspect the power supply. I had issues with a box I built a while ago, It would work fine, and when I lit a certain amount of leds, it would reboot. Interesting thing was, some outlets would work fine and others it would reboot. So I know this indicates weird power in the house, but I think it was more that the PS was very crappy and sensitive, I got a higher quality one and the problem totally went away. Luke

Yes! I have 8 3372's at home waiting to for just this project. I was really into doing it about half way through my 6582 but then I burnt out a little. But I'm feeling ready now. I don't know much about layout at all, but would be happy to help if I can. I have done a little research on the original xpander filter. I'll dig around my files and see what I can come up with. Luke

Excellent work! I love it, but also agree with Stryd, the first knobs are sweeter. Luke

When I got my Virus A second hand it still had the price sticker on the bottom and it read "Waldorf Access Virus". I have also heard rumor that the Waldorf guys helped design/implement the wave table features on the TI. Anyone know if this is true? Luke

Didn't make it to the festival this year, but every other year Pullen totally brought it. Luke

Hey Wilba, I was waiting until I get the fan for the back until I sent out "official" pics. You can check out some more pics here: http://www.flickr.com/photos/26368076@N07/ Thanks again for all the hard work that has gone into this great project. The green smash led's with 1k resistors match the brightness of my lcd almost perfectly. Like they were made for each other. If I can offer one suggestion for everyone building this, be very very careful and take extra time and effort when making your ribbon cable to connect the two pcbs. This is where I made my biggest screw up. Unless you do a great job on this part it will cause you much pain in the future. Remember every time you open up the case, and that will be often, you are stressing these connections. I ended up having to completely redo mine, and I almost ruined the pcbs. Besides this it could not have went smoother. Luke