4053 | picaxe midi

hi,

i am looking for an easy way of using an audio signal to switch connections on and off.
i figure i would use a relay and drive it with something like this

any ideas or hints where i might look around for different schematics etc ?
the whole thing should run on 5v and be possible to build on a small piece of perfboard.

something that doesn`t use a relay / isolator might also work for me if it pulls the signal i want to switch to ground.

There’s a kit here for a “hand clap” operated switch. I reckon any noise may work though. Runs on 12V though.

http://www.maplin.co.uk/clap-activated-switch-kit-31920

I don’t really understand what is supposed to trigger what, but I suppose that you need some envelope detector with a gate (one dual opamp is enough for this job), and a switch. You might want to work with 4066 / 4051 / 4053s if you don’ want to mess with relays.

thanks guys.

@MicMicMan: i think you understood me right. i want to get a gate from an audio signal and i want to use that gate to open/close a connection between two contacts.
i want to use it for circuit bending: have an audio signal close contacts is basically what i want to do.
any example about the dual opamp thing you are talking about? do you mean a opamp schmitt trigger?

i also found this which would do the job i guess. it uses a single transitor for the gate and a 555 timer for variable time.
the only thing is i will have to figure out how to connect a line signal instead of the mic.

i figured out another way to do it:

why use a audio to trigger converter, when there is midi?
i now have a working proto with a picaxe 20x2 that toggles switches (in a 4053) to the beat of the midi clock.

one question about the 4053 (i use CD4053BE): i inspected that there seems to be some bleed throu from somewhere to the switch inputs/outputs. (looks like a few mV are getting through from the 5v line) i now there is no 100% isolation in those like in a relay or optocoupler, but i didn`t think it would be that noticable.
i use it for switching bend points in a video mixer. maybe it is that task that it is not that good to use for (hf signals).
i looked at the polivoks schematic and didn`t find anything that is much different.
is there anything i have to take care of, for improving the isolation performance of this chip?

@fcd72 / anybody else who uses picaxe:
right now i only react to midi clock messages.
i know in theory, how to make it respond to other messages (cc etc.), but i was wondering if there might be some kind of midi library for picaxe that i might look into befor trying myself. please post links, if you know of anything like this.

i think with the right firmware this thing might be interesting for other circuit bending applications. it is a really small circuit (only optocoupler, picaxe, 4053 and a few resistors basically) with the hardware it is theoretically possible to get bend stuff to react to any midi messages (only clock right now)
if anybody is interested, i can share the schematic and picaxe program.

are every control pins of your 4053 well set to a defined voltage? If some control pins are left floating, you can have such issues with a switch like that.
If you’re working on a breadboard, it’s also likely that you get some bleedthrough because of the breadboard, especially working with HF.

@loderbast
Do you run the 20x2 at 64Mhz with setfreq m64 ?
There is no MIDI Library for the PicAxe, i can well send you my revised MIDI Handling Code that uses input driven hserin and a circular Buffer (this is new) and is is quite optimized. If you want to drive a display and don’t want to scramble up MIDI messages i can as well pass you the CodeBase for the OctoPot for the 28x2/40x2 which has an integrated Display driver so you get rid of the either blocking or sometimes (if you run into the hserin interrupt) bad functional serial Display.

And, as MicMicMan pointed right you should pull address pins and unused I/Os with 10k to GND. Maybe you’ll try a 4051 for better results as this one handles only one Signal (1x8 Switch).

Seems that the Proto Board mentioned in this thread inst as useless as i thought :wink:

@fcd:
jup. i run at 64Mhz at the moment.
i am really interested in your code with the circular buffer. and the new octopod code.
In fact i used your code from the octopod 20x2 proto as a reference.
i am still using 20x2 by the way.

what i am looking for is a good way of handling the fact that midi messages do not all have the same length and one can not be sure if there is already a full message in the buffer, when the interrupt gets called. (its easy for clock because that is only 1 byte)
the circular buffer sounds like something that can be usefull here.

i think you still have my email adress (its the paul h. one)

@micmicman:
thanks for the tip. i still had part of the circuit on breadboard when messuring. i will hook up the whole thing later and see, how it turns out on perfboard…
i think i hat all controll inputs set propperly when trying, but i am not 100% sure.

@loderbast
In fact the Interrupt is called as soon as the actual command is finished (all commands are blocking the Interrupt) and at least one byte was received within the time the picaxe processed your command - which it does blazingly fast like a glacier, hence the question for 64MHz, then its as fast as a glacier melts. You will have to keep track of the running status so you’ll have to parse the whole MIDI stream.
Running Status is a trick to save precious bandwidth, if no Status Byte is sent the Data sent is meant to be of the same type as the Data Bytes before thus saving a Byte for the Status. All MIDI Devices are expected to keep track of the Status.

So the basic thing to do is:

  • read a byte from the buffer
  • if its not a status byte (bit8 is 0 for the status bytes Value is <128, its faster on the PicAxe to check for the Value than to mask the bit or puth the value in a0 and check bit8…) its probably a Data Byte. Check the running Status to see what kind of Data it is. You’ll have to parse the ones you want to process, all others can be ignored
  • if its a status byte update the running status (bit8 is 1 for the status bytes Value is >127)
  • if you want to insert data into the stream be shure you processed all the buffer and then resend the Running Status Byte after your Message if the next byte received is Data.

Here is a chart i use while coding MIDI related stuff on the PicAxe, it might help - if you figure out what i mean :wink:

One word to the buffer: i switched to the circular buffer because you never could have been shure there is a byte (or more) received while processing the resetting the buffers pointer so this data gets lost - this caused some of the glitches you reported, if you understood the concept of the Running status you might imagine what happens if you miss a Status Byte (say NoteOff)… Using the circular buffer means that you don’t need to reset the Pointer and don’t touch the way the PicAxe writes into memory, you just run behind, hopefully fast enough the buffer doesn’t get filled completely. You then have the same problem…

@fcd72:
thanks that already helped a lot.
i did not realise it is that easy to distinguish data and status bytes that easily. (never looked at the bits but only at the hex values so i did not notice, all data bytes have bit8 = 1)
i think i get the running status concept.

i also think i also got the circular buffer thing. i would be happy to look at some of your code anyways. (paul [at] h3nninger |dot|de)

if i get it right, you just dont reset the hserptr and reading pointer to 0 but let them overflow so that every byte stays in buffer while less than bufferlength-1 new bytes are recieved and dont lose stuff that is recieved while the interrupt is running.

Here are some Code Snippets:

@
init:

Here are all declarations missing but i think you’ll get it - buffer size is for 20X2

'SERIELLE SCHNITSTELLE EINSTELLLEN 31250baud, background receive
hsersetup B31250_32, %001

'INTERRUPT SETZEN BIT 5 HIGH FÜR INTERRUPT BEI RECEIVE
hserptr = 0
midi_lastByteRead=0
midi_controllerDataSent=0
setintflags %00100000, %00100000

main:
Insert your useful program here

interrupt:
midi_buffer_endposition=hserptr
midi_firstByte=1
DO UNTIL midi_lastByteREad = midi_buffer_endposition

'BYTE AUS DEM BUFFER LESEN
get midi_LastByteREad, midibyte

'WENN DAS ERSTE BYTE DATA IST UND WERT GESENDET WURDE EINFACH RUNNING STATUS BYTE SENDEN
IF midi_firstbyte =1 THEN 'ERSTES BYTE???
midi_firstbyte=0
if midibyte < 128 THEN 'DATENBYTE???
if midi_controllerDataSent =1 THEN 'WERT GESENDET???
'RUNNING STATUS BYTE SENDEN
hserout 0,(midi_runningStatus)
'sertxd ("RESENT ",#midi_runningStatus, 13)
midi_controllerDataSent = 0 'WERT ZURÜCKSETZEN
END IF
END IF
END IF

'RUNNING STATUS UPDATEN
IF midibyte > 127 AND midibyte < 240 THEN
midi_runningStatus=midibyte
’sertxd (#midi_runningStatus,13)
END IF

hserout 0,(midibyte)

IF midi_lastByteREad = 127 THEN 'OVERFLOW?
midi_lastByteREad=0
pulsout redLED, 1000
ELSE
inc midi_lastByteRead 'NÄCHSTE ADRESSE SETZEN
END IF
midi_buffer_endposition=hserptr
’sertxd (#midi_lastByteRead, “/”, #midi_buffer_endposition,13)
LOOP
’SERIELLE DATEN FLAG ZURÜCKSETZEN
hserinflag = 0
’INTERRUPT SETZEN BIT 5 HIGH FÜR INTERRUPT BEI RECEIVE
setintflags %00100000, %00100000
RETURN

You will have to change the .jpg to .bas…

i think i got how it works.
thanks a lot. that helped me a lot.

this is what i got so far:
http://vimeo.com/50089735

i did not even start getting serious with the midi in code, because drilling, dremeling and soldering took really long. (i thought using 25pin D-Sub connectors was a good idea until i had to make holes for those)

i also kind of killed a ave3 in the bending process. video input is not working any more, but it still is usable for generating abstract video patterns.

nvm

@loderblast: AVE3 are great. My girlfriend loves to use them for visuals.

@flip
since i am german i comment my code also in german in prepsration of my plan to take over the world.

@fcd72 It has been tried before and look what happened to him :slight_smile: We don’t mind the MIDI or synth world being conquered though.

@fcd72: yep yep, I’m still not really awake and didn’t look very close. As your comments are all caps I thought they were actually part of the code…

you can download the development software for free and see the coden all its blue/red/green/blackish glory…

@loderbast very nice job, you did. Flip is right, i love my bended AVE :slight_smile: i tried a smiliar thing with my bended NES. But without using a picaxe. But it doesnt work properly. I like your way and i am interested in your schematics. :slight_smile: