Searching \ for 'MIDI Pic Page' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'MIDI Pic Page'.

Truncated match.
PICList Thread
'MIDI Pic Page'
1999\03\21@101657 by Ross Bencina

flavicon
face
Hi there,

I have just created a "DIY MIDI Controllers using PIC Microcontrollers and
Basic Stamps" aggregation page, you can access it at:
http://www.audiomulch.com/midipic/. It's intended as an introduction for
people with some MIDI background who are thinking about using PICs and
Stamps.  Suggestions, comments and URLs for MIDI PIC and Stamp sites that
I've missed would be greatly appreciated.

Also a question:

I've recently been fooling with a 10Mhz 16F84 to make a cheap MIDI knob box.
My design works well, but only transmits MIDI. I would like to be able to
write code to parse an incoming MIDI stream and merge my output with it. I
have a theory that this might barely be possible in software on a 10 Mhz
16F84. Can anyone say that this has actually been done? Alternatively are
there any UARTS that I could combine with a 16F84 to do MIDI?


Thanks,

Ross Bencina
<spam_OUTrossbTakeThisOuTspamaudiomulch.com>

1999\03\21@112004 by Mario I. Arguello

picon face
I have a Yamaha RX11 drum machine as well as the famous DX7 keyboard.

I would like to build some dum pads (you know the type with piezo xducers).

Anyone done anything in terms of a drum controller/mixer with PIC chips?

Thanks.

Mario

1999\03\21@113454 by Ross Bencina

flavicon
face
Mario I. Arguello writes:
>I have a Yamaha RX11 drum machine as well as the famous DX7 keyboard.
>
>I would like to build some dum pads (you know the type with piezo xducers).
>
>Anyone done anything in terms of a drum controller/mixer with PIC chips?


There was an article in  a recent issue of Electronics Today International
(sorry I don't have the issue number) entitled "MIDI Drum Pads" by Tom
Scarff which did exactly what you are requesting. It was implemented using a
PIC16C84. each transducer was connected to a data pin using the following
circuit:

ground -> transducer -> 4k7 resistor -> PIC data pin -> 1k5 resistor ->
ground

When a transducer is struck the data pin goes high. The software scanned the
pins and outputed midi events accordingly - It didn't do velocity though.

Ross.

1999\03\21@133507 by Mario I. Arguello

picon face
Thanks Ross, anyone have a copy of that article? Any others have info?

Would sure apreciate as much info as I can get on this subject. I
amconsidering doing the drum Machine controller but would like it to have
velocity sensitivity.

Thanks.

Mario

1999\03\21@134951 by Ryan Pogge

flavicon
face
I think I have asked this in the past but....
I have this old Roland SCB-7 MIDI daughter board
it was piggy backed to my old sound blaster 16 card.
I have no use for it now, and was wondering if I could run
midi through it from a PIC somehow... Problem is I cant find
and tech stuff on it so I have no way of telling how it works
or even what the pinout of the header is.....
if anyone has any ideas or can help me I would realy apreciate it...
thanks,
Ryan




{Quote hidden}

box.
{Quote hidden}

1999\03\22@171349 by John Payson

flavicon
face
|I've recently been fooling with a 10Mhz 16F84 to make a cheap MIDI knob box.
|My design works well, but only transmits MIDI. I would like to be able to
|write code to parse an incoming MIDI stream and merge my output with it. I
|have a theory that this might barely be possible in software on a 10 Mhz
|16F84. Can anyone say that this has actually been done? Alternatively are
|there any UARTS that I could combine with a 16F84 to do MIDI?

The bit time for MIDI is 32uS, or 80 cycles at 10MHz.  Maybe possible,
but that's **REALLY** pushing it.  I'd say using one of the 28-pin or
40-pin PICs would be better, esp. since they can have an A/D built-in.

Note also that merging into the incoming data stream isn't nearly so
simple as you might want it to be.  Beyond the fact that transmissions
can come in at any time, there's also a requirement to manage what's
called "running status".  In particular, the MIDI spec allows for any
number of key-up, key-down, knob-change, etc. commands to be sent with-
out having to re-send the command and channel number; you need to watch
the incoming data and keep track of what command (if any) is current.

For example, suppose a synth on channel 3 has sends note-on events for a
C minor chord (all 3 notes at velocity 64).  Its data stream would look
like:

 92 3C 40 3F 40 43 40
               ^
if there were a slight delay before hitting the last note, that might
produce a pause where marked by the arrow.  If your knob-change cont-
roller happened to insert its event there, it would be necessary to
send another "92" before sending the "43 40" for the last key.

Note that following normal channel events, there should be an even
number of bytes of data.  If you receive an odd number of bytes, you
may want to hold the last byte until its "mate" arrives [or at least
its start bit is detected].

1999\03\23@020110 by Ross Bencina

flavicon
face
From: John Payson writes:
>|have a theory that this might barely be possible in software on a 10 Mhz
>|16F84. Can anyone say that this has actually been done? Alternatively are
>|there any UARTS that I could combine with a 16F84 to do MIDI?
>
>The bit time for MIDI is 32uS, or 80 cycles at 10MHz.  Maybe possible,
>but that's **REALLY** pushing it.  I'd say using one of the 28-pin or
>40-pin PICs would be better, esp. since they can have an A/D built-in.


Would the built in UART on these chips be usable for MIDI - would it provide
a notable advantage? I've been considering using a MAX3100 serial UART in
combination with a 16F84. Mainly because I'm just getting into this stuff
want to keep it cheap and simple. I realise that there is a point where
"cheap and simple" becomes "more expensive than a 40 pin PIC and quite
complex also", but I don't yet have the background to make these decisions -
comments would be welcome.

>Note also that merging into the incoming data stream isn't nearly so
>simple as you might want it to be.

Yes I have considered that.

Regards,

Ross.
<rossbspamKILLspamaudiomulch.com>

1999\03\23@045537 by Gerhard Fiedler

picon face
At 17:00 03/23/99 +1030, Ross Bencina wrote:
>From: John Payson writes:
>>|have a theory that this might barely be possible in software on a 10 Mhz
>>|16F84. Can anyone say that this has actually been done? Alternatively are
>>|there any UARTS that I could combine with a 16F84 to do MIDI?
>>
>>The bit time for MIDI is 32uS, or 80 cycles at 10MHz.  Maybe possible,
>>but that's **REALLY** pushing it.  I'd say using one of the 28-pin or
>>40-pin PICs would be better, esp. since they can have an A/D built-in.
>
>Would the built in UART on these chips be usable for MIDI - would it provide
>a notable advantage?

definitely -- i suppose that's the reason john suggested the 28+ pin parts
(so far, microchip only gives you a uart in 28 or more pin cases).

>I've been considering using a MAX3100 serial UART in
>combination with a 16F84. Mainly because I'm just getting into this stuff
>want to keep it cheap and simple. I realise that there is a point where
>"cheap and simple" becomes "more expensive than a 40 pin PIC and quite
>complex also", but I don't yet have the background to make these decisions -
>comments would be welcome.

the serial uart might be an option, considering that you can stay with
flash that way. i think the point is that you need a hardware uart --
internal or external. internal has some advantages (like parallel access
and interrupts), but you have enough headroom to deal with a serial uart.

ge

1999\03\24@121841 by John Payson

flavicon
face
|>I've been considering using a MAX3100 serial UART in
|>combination with a 16F84. Mainly because I'm just getting into this stuff
|>want to keep it cheap and simple. I realise that there is a point where
|>"cheap and simple" becomes "more expensive than a 40 pin PIC and quite
|>complex also", but I don't yet have the background to make these decisions -
|>comments would be welcome.

|the serial uart might be an option, considering that you can stay with
|flash that way. i think the point is that you need a hardware uart --
|internal or external. internal has some advantages (like parallel access
|and interrupts), but you have enough headroom to deal with a serial uart.

One concern I'd have with using a serial UART would be keeping a
consistent delay between the input and the output.  While there
are obviously limits as to what one can do (e.g. if a key event
comes in while you're just starting to send out your knob-change
event) the MIDI data stream is inherently real-time and so you
want to keep any delays as (1) uniform, and (2) short as possible.

One thing I'd suggest, btw, even if you use the internal UART, is
that you tie the data receive line to RP0/INT as well; you can thus
tell when a data byte is starting to arrive and react appropriately
(e.g. if you receive:

 90 4C

and retransmit it, you'll not be able to insert any data of your own
until you've received and retransmitted the next byte from that data
stream.  What would be good, then, would be to avoid sending the 4C
until you know that the next byte is on the way.  Too bad I'm not
aware of any "byte being received" flag on the PIC.

BTW, an alternative approach would be to design the board so that all
"through" data had a consistent delay of 5 character times.  This would
let you wait until there were 4-character-time "holes" in the incoming
data stream in which to place your knob-change commands.  Although the
delay of data going through your box would be longer than otherwise, it
could be made very consistent.

1999\03\24@135200 by Gerhard Fiedler

picon face
At 11:00 03/24/99 -0600, John Payson wrote:
>One thing I'd suggest, btw, even if you use the internal UART, is
>that you tie the data receive line to RP0/INT as well; you can thus
>tell when a data byte is starting to arrive and react appropriately
>(e.g. if you receive:
>
>  90 4C
>
>and retransmit it, you'll not be able to insert any data of your own
>until you've received and retransmitted the next byte from that data
>stream.  What would be good, then, would be to avoid sending the 4C
>until you know that the next byte is on the way.  Too bad I'm not
>aware of any "byte being received" flag on the PIC.

is that really a problem? i guess that the spec says (though i don't have
exactly the specs here) that the receiving device should just ignore
incomplete messages like this one. so i guess there's not much difference
between inserting the controller message after the 0x90 or after the 0x4c
-- if it takes too long for the next byte to come in. in any case you'd
have to repeat the aborted message with the complete data, but i guess this
doesn't make much difference whether it occurs before or after the first
data byte. (a "byte being rx'ed" flag would be nice, though... :)


>BTW, an alternative approach would be to design the board so that all
>"through" data had a consistent delay of 5 character times.  This would
>let you wait until there were 4-character-time "holes" in the incoming
>data stream in which to place your knob-change commands.  Although the
>delay of data going through your box would be longer than otherwise, it
>could be made very consistent.

hm... you would get pretty consistent delays, but delays bigger than
necessary. the problem with midi delays is not only that they have to be
consistent within one midi connection, but within a whole setup of many
connections, and in this context the relatively long delay of 4 character
times seems not to be justified. if you do it "conventionally," you cause
only once in a while a 3 char delay max (when you put the occasional switch
controller message into a stream full of data), whereas most of the time
the delay is as short as possible (a lot shorter than 4 character times).

i think the downside of a (in very rare occasions) inconsistent delay is
more than balanced by the shorter delay (for almost all transmissions).

ge

1999\03\25@135726 by John Payson

flavicon
face
|is that really a problem? i guess that the spec says (though i don't have
|exactly the specs here) that the receiving device should just ignore
|incomplete messages like this one. so i guess there's not much difference
|between inserting the controller message after the 0x90 or after the 0x4c
|-- if it takes too long for the next byte to come in. in any case you'd
|have to repeat the aborted message with the complete data, but i guess this
|doesn't make much difference whether it occurs before or after the first
|data byte. (a "byte being rx'ed" flag would be nice, though... :)

Do all devices in fact ignore incomplete messages?  I know that
few keyboards actually use the velocity associated with a key-up
event; I don't know if they actually wait for it.

>BTW, an alternative approach would be to design the board so that all
>"through" data had a consistent delay of 5 character times.  This would
>let you wait until there were 4-character-time "holes" in the incoming
>data stream in which to place your knob-change commands.  Although the
>delay of data going through your box would be longer than otherwise, it
>could be made very consistent.

|i think the downside of a (in very rare occasions) inconsistent delay is
|more than balanced by the shorter delay (for almost all transmissions).

I agree that *probably* isn't the way to go; it's often nice to
keep in mind one's options, though.

BTW, one goofy little gizmo I built is a sustain pedal->MIDI
converter which produces nothing except control messages for the
sustain pedal.  The thing runs off a 9 volt battery and uses ZERO
battery current when the pedal isn't depressed (the pedal powers
and unpowers the circuit, and the storage cap has enough juice to
send the pedal-up message when battery voltage goes away).  Cute,
eh?

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...