ultra

if you decide it's easier to send one shipment into the states and need them sent out from there, i (and i'm sure plenty of others) would be willing to help.

perhaps this should be in the "assembler" category, but i really know nothing about that language and i'm hoping for a c related response. also the application i'm writing for my control surface will be in c. i want to use two cores together with mbnet for my control surface application. basically, i just want simple communication for this purpose: core 1 tells core 2 what layer it's on, so core 2 can change states appropriately. core 2 tells core 1 what knob/switch has been changed, so core 1 can send out the commands on that interface. are there any programming examples out there? i've searched the forum and ucapps and i haven't come up with anything. i've also tried looking at the sidv2 software but it's a bit beyond my understanding. is mbnet considered to be just for advanced programmers, or is it just that not many have used it so there isn't much information out there yet? any help at all on how to get started with this would be much appreciated! ultra

as soon as i verify this design works, i'm going to open a bulk order thread and probably do the wiki thing as others have been doing. it seems to work well.

here we go again with another pcb design. this one is a bit more specialized so i'm not sure i'll find others interested, but i'm throwing it out there anyway. while making the core/bankstick/iic board, i received a lot of good feedback from others about how to design it, and any help on this one would be good for me as well. i've been working on a control surface for ableton live. the basic design is inspired by the one sasha is making (nice work btw) but there are major differences. my main control area for the 8 tracks has 56 encoders and 64 buttons (switch matrix). that pcb is all laid out and ready to go. since i've filled a core, i want a two-core design that can talk via the CAN interface so one core can tell the other which layer it's on so the encoders/buttons can change functions accordingly. also, the two core design allows me to have separate midi interfaces to the computer. one is general midi cc's and the other is the mackie protocol to control some of live's functions. the way i want to use this box (all 16 midi channels available for cc's and notes), i can't simply merge midi. the downside is using up two midi connections to the pc. my solution is to integrate two midi to usb connections right on the core, and hopefully add headers that can connect to additonal usb devices. i want an integrated touchpad mouse on the box, so that would be one. also, an extra usb connection on the back of the box would be great since i can plug in whatever midi controller (trigger finger, axiom, xboard, etc) i'm using at the time. thanks to sinesurfer's suggestion, i'm going to try basing the midi/usb stuff on "midinator". has anybody here made their own usb hub? i realize it's much easier to rip open an existing one, but i'd like it to be integrated into my pcb. if i have to use smd components for that part, so be it. also, is anybody by chance interested in a similar pcb design?

sorry it's been a while since i've done anything with this. i've been short on money but i also admit that i'm a bit daunted by the pcb making process, as i've never had one manufactured before. this will be a good learning experience since i have a few other pcbs i'll eventually need to have made as well. gold phoenix seems to be the easiest choice for a few reasons. the first reason is that i can give them my design and they'll fit as many as they can into 155 sq inches for $100. i can fit 7 of these boards into that space so i figure it'll be around $15 per board after splitting their shipping cost with the pcb price (like $14.20 each). i'm not sure if anybody considers this price to be high or low, but this is what i have so far. i'm also not sure if the 155 sq inches means total overall space, or would they have to fit into a certain panel dimension-wise. also, i can order a single panel to test it out before having more made without any extra costs. the $100 is what it is. in the future, people aren't missing out on the group buy. all they have to do is get a quantity of 7 and i can have more made. so, does around $15 plus shipping from the united states to wherever you are sound like a fair price? if not, does anybody want to get in on the ordering process and help me get the price down more? it's not a big board (160 x 80 mm) but there's a lot of holes (636), and i think some manufacturers take that into account with pricing.

i'm definitely in for 100 gray on black, d-shaft type.

the major difference between the solid wire and the stranded wire is that you want to use solid wire when it's on the board and use the stranded wire when the wire is coming off the board so it doesn't break from movement.

thanks tk. i saw the snapshot but i wasn't sure if the computer would see this as two ports. i'll go back and read again.

does midibox usb show up in the system as two separate midi inputs, or does it combine the signal into one? i read ucapps but i'm not sure it answered this question. thanks!

i think i hashed it out. i need to use two midi inputs. one will be the mackie control, the other will go to the various channels.

after looking into it a little more, ableton seems to lock channel 1 from doing anything but mackie protocol specific commands. i'm seriously considering finding a DIY keyboard module to send the tab, shift+tab, and arrow keys since i'll have a usb mouse in the box anyway. not allowing you to map to these controls seems to be a pretty big oversight for ableton.

i get that it IS midi, i just thought it was strange that note values would be used instead of control change 0 and 127, so that your controls wouldn't be triggering instruments if they were on the same channel. so the basic answer is "yes", but since i can remap things (i hope), then the answer might be "no". thanks :)

i've been reading up a bit on the logic/mackie control protocol, and it seems most button commands are simply note numbers with a value of 0 or 127 on channel 1. this would seem to me that channel 1 would become useless for anything but the lc protocol because it would be sending notes to any instrument you have on that channel. the way i want to organize my control surface would be to use all 16 channels and have each be available for anything. most of what i want to do can be mapped to ableton live using midi, but certain functions, such as clip/instrument view and session/arrangement view can't be mapped to midi (as far as i know), but are available by using lc. so basically, do i have to decide between using my form of organization on the control surface (using all 16 channels for anything i want) and using the lc protocol for 2-3 functions that i can't get via midi? thanks!

thanks guys. i've only been programming using mios for the past week (it's my first c programming besides my class in school) so i haven't seen a lot of this kind of thing yet. tomorrow night i will definitely be playing around with this and try to better understand what you guys have said. :)

it is called "relative midi" in both the live and axiom manuals. sure it's no different than sending the same absolute values repeatedly (unless acceleration is taken into account), but it's still a standard that almost all DAW's will recognize (i read reaktor understands it as well), and some controllers will send. in fact, live accepts four modes (signed bit, signed bit 2, binary offset, and 2's complement) and i think the axiom can send six. in signed bit mode, sending a CC with the value 65 tells live to increment 1 value. sending a value of 1 tells it to decrement. the incrementing values can be anywhere from 65-127, and the decrement values are 1-64. when live is in midi learn mode, it looks at the values being received and not just the control change number and channel. if it receives two commands in a row that both are at 65 or 1, it understands signed bit is being used and automatically puts itself into that mode. then (again without acceleration being taken into account) my controller repeatedly sends 65 to increment or 1 to decrement. when moving the encoder faster, the values of 65 and 1 increase to tell live to move the knob faster. sending 65/1 is actually very slow, high resolution movement and it doesn't have a normal feel to it. this is why i used 67/3 instead, to add 2 values (movement seems to increase exponentially with higher values) and make the movement seem more natural. so the DAW is actually taking acceleration into account by responding differently to different values, but it makes sense that the controller would decide how much it is being accelerated. one thing to note: if you have live in midi learn mode and the controller does not send 65/1 (say you move an accelerating encoder fast), live will get confused and default to absolute mode. so your "slow" mode should be used to send the correct 65/1 values. otherwise while in midi learn mode, live does have a drop-down box to choose which mode you're using, so you can still get away with sending incorrect values.

i don't think any program understands acceleration. when i send signed bit out from my axiom, the value increases with the speed. so the acceleration is built into the keyboard. i'm not sure i see a purpose for acceleration now that i have this working properly. a value of 3/67 seems to work perfectly, as it does a full turn in about 3/4 of a knob turn. perhaps a button to temporarily increase the value would be more appropriate.

thanks stryd, this works perfectly. and for anybody else researching this, here's some answers: relative midi generally sends the value 65 repeatedly to decrement, and 1 to increment. using midi learn in ableton live, live will autmatically recognize it as signed bit if you turn the encoder slowly. after receiving 1 or 65 twice it understands it's signed bit. however, this moves the knob too slowly. changing the values to 3 and 67 works perfectly for me (might end up changing by 1 value), but live won't recognize it as signed bit anymore. so when in midi learn mode, just manually select it from the drop-down list on the bottom of the screen. thanks again stryd :)

i've been playing around with mios programming in c for the past few days. i'm using endless rotary encoders and i've figured out how to get a knob to turn properly in ableton live using absolute midi values. what i want to do now is use a relative mode in ableton live. i've figured out how to use signed bit (sending 65 or 1), but it seems to take a lot more turning of the knob than when sending 0-127 values. this seems weird to me because they should increment in the same amount. for absolute values, i increment a counter by 1 on each encoder move event. for relative values, i send the 65 value at the same frequency. it takes a lot longer to turn the knob in relative mode. i see that there are speed settings available, but i don't want to lose resolution. i don't understand why using a counter would be any different than sending the command to increment repeatedly. any ideas?

group buy!!!

this seems to match the pinout of nebula's group buy lcd, except the anode/cathode seems to be switched. i can't verify from where i'm at because it requires chinese text to read the pdf and i can't do that here. do you think nebula's lcd pinout is different just because the anode and cathode aren't on the header? what i'm getting at is this is 1:1 compatible with my ultracore (http://www.midibox.org/forum/index.php/topic,11057.0.html) if i changed those pins around. i'm wondering which way is more standard because that's the way i wanna do it. edit: sorry i went ahead and verified this for myself. my core module is gonna be changed and will be compatible with this and a lot of other lcds :).

yes i now see the mackie control protocol on the wiki. this offers a lot more control :)

only the basic layout is based on yours. as i work on it, it's changing a lot to be my own. i haven't really looked into lc at all because i was going to write a program from scratch and only control what i can via midi. i'll look into lc more and see what it's all about, thanks. perhaps this is the route to go if it gives me more control.

yeah i use live but i haven't done as much with routing audio out thru a send to a compressor and back, etc. i would mostly make loops in reaktor and put them together in live and i didn't go much further than that. i see how to add more sends now. i've been trying to find some of the functions you're using in live. i can't figure out how to assign session and arrangement view to midi, and left/right for the navigation buttons. also the fast forward and rewind buttons on the transport.

awesome, i would have been ok even with this: [------------####--------------------] i really look forward to writing a mios app!

one more question, how difficult is it to do the programming for somebody who only knows a bit of c (finishing up a beginners course)?