stryd_one

Oh holy crap you did the switch! I haven't heard any cries for help in the chatroom so I assume it's going smoothly? Rock on dude....

IIRC there's a reason why MBHP cores don't support ICSP.... But uhm...I can't remember.... TK?

Well that's just silly, you're sending more data than you can visualise - the LEDs don't even light up that fast. The problem here isn't a lack of bandmidth from MIDI, it's an excess of data being sent from max.... so to answer your question "Midi bandwidth. Advice?": My advice is to fix the problem, and it ain't midi.... It's your software. Sorry :(

Just to balance things out, there are generally three schools of thought on autorouters: 1) They suck, don't use them 2) They suck, but on complex boards they can experiment with the layout faster than you ever could, so you can take a hint from it, and then rip it all up and do it manually - because autorouters suck, remember? 3) Who cares, just autoroute it Given that this isn't a complex layout at all, 2) does not apply... And given that it's very simple, 3) is overkill.... leaves us with the generally accepted answer: 1) They suck, don't use them Edit: and nils is right, that's how tagging works well :)

Yeh, what nils said. I don't know how many times you expect us to react kindly to this spamming you've got going on, but it won't be many more from me.

She was so fine until she had plastic surgery. Ahh well...

If you search more, you'll also find the doco that says you should install the parts even if you don't use CAN.

Gee that musta been hard. dstamand do you work for those guys or something? Does it open FPD files too?

That one looks suspiciously 2x20 ;)

hahaha thread has been appropriately tagged. while (!sure) { PlaceBlame(optocoupler,damnedthings.suck); if (IsWorking(core) && !changedopto) sure = 1; } Now it's someone else's turn to play "Blame the opto". Most original joke wins an opto!

WELL SAID!!! That needs to go on the FAQ or something man. Anyone who can think of an appropriate place to record it please do!

AAaaaaand we're back to 8 bits: SDCC pic16 port error: the port currently does not support *reading* bitfields of size >=8. Instead of generating wrong code, bailling out... make: *** [_output/main.o] Error 1 That's erroneous, it doesnt support >8 (=8 is ok)

We've got ample quantity I think, and youre not too late. Although. it is technically "tomorrow" now so I must get to bed! ;)

Kinda... The trick is to move away and circle it like a hungry shark... Contemplate the right time and angle to attack.... Then when the time is rigt you can bite it's fricken head off ;D

You don't know many aussies do you? ;D

Try them anyway.... This wouldn't be the first time that way of thinking caused disappointment ;)

Running out of bandwidth with 64 notes going in? I doubt it.... You can't increase the bandwidth but for this, I don't see why you'd need to. I think you might be chasing a problem that lies elsewhere. What makes you think you're out of bandwidth?

Price? Just four MILLION DOLLARS

Never noticed that! I'll look into it....

Well you can build a midibox using an infinium fader (you'd have to pioneer it though...it's not hard if youre experienced) and normal pots/encoders/switches for the other stuff... Not sure about modding existing kit though...

They're the same only bigger :) I could ask, but I'm not sure.... It'd certainly need to be >100 but your order is, so.... yeh I'll see. If more people are interested that would help. I may run a 2nd order, especially if Wilba does a layout using these, cause we all know what happens when wilba does a layout....We're gonna need a lot ;D

Hahahah ... confession: I did that when designing the footprint for a battery holder. A CR2032 will not fit in a 10mm diameter ;) hehehhe

Heya SullX, Glad you've got your head around it now :) Sorry I didn't post before, but Lyle said basically exactly what I was going to, no need to echo :) What you are referring to, is the job of a sequencer. A sequencer will play back a series of messages to be sent down the midi cable, in a given order. It works just like sheet music, but instead of saying "play a C note for 1 quarter of the bar", it says "turn the C note on"...and then, one quarter later, "turn the C note off". Most MIDI sequencers will give you what is called a piano roll. It looks like this: (ignore the menus on the left, it's the stuff on the right you want) In that picture, each row represents a midi note number. In the musical world, that relates to a key on a piano, or a fret on a guitar string. In your robot, each row could represent one valve. You can see vertical lines separating the sequence into musical bars. Just right of the 2nd bar, you can see a darker vertical line - that's where the sequencer is now. As the sequencer plays, that line travels from left to right, and as it crosses over the beginning of one of the blue rectangles, it sends a midi Note On message.... as it crosses over the end, it sends a Note Off. You draw in the rectangles with your mouse, and stretch and shrink them to be the correct length. In your robot, you could set it so that when a Note On is recieved, it opens a valve, and when the Note Off is recieved, it closes the valve. You can probably imagine how a timeline of events to animate your bot, would look on a piano roll. Of course, it doesn't all have to be locked to a musical timeframe. You can place your notes wherever you like :) Edit: Oops forgot. The pic above, would represent one midi channel. Because the midi channel is part of the midi note on message, you can't just ignore it - but you can just pick one channel and go with that. This means that your controls would be very simple: 90 xx yy These are three hex bytes. The first is split in two; 9 and 0. The first half (most significant byte) 9 is a note on message - but it can also be a note-off message - I'll come back to that. The second half (least significant byte), the 0, is the channel. You only needone, so hey, we'll go with channel 1 (the computer counts from 0, but it's still the 1st channel, so channel 1 it is ;)) The second byte, xx, would be a number, between 0 and 127, which would identify which valve the message refers to. This in midi is the 'Note Number' The third byte, yy is known in midi as velocity. The velocity is supposed te represent how fast you hit the piano key, so it usually represents how loud the recieving device will play the sound. If the velocity is 0, that equates to a note off message (told you I'd come back to that). You only need the valves open or closed, so you can just 127 to open the valve, and 0 to close it. This is very simple to do in MIOS. You can find an example of how to drive 128 LEDs from a midibox, the same code applies to you - just, instead of lighting an LED, you're opening a valve :) And yes, that's really as much code as you need. OK you could make it more flashy if you wanted to, but.... That will do the job. Certainly for a prototype :)

Are you volunteering? :) If not... STFU! :D No I'm just kidding. But really, There are two options here: Write it yourself, or wait. Oh... or pay stryd_one and he'll quit his job and write it for you. Speaking of my job.......

1st: Sorry I edited your post - I just cut out the 10 empty lines at the end, no other changes :) Please paste the logs. When you transmit sysex it should be rec'd exactly as it was sent. I'd like to see that with my own eyes - this would not be the first time that sysex was corrupted in such a loop and it went unnoticed. I don't think that's it though. It seems like you might have a short or something. Did you triple-check the polarity of D1? If you got that backwards that would explain this fault. If you could post the results of the rest of the test that will be helpful.