MIDI CV trigger met pic

[Natural_Demon]

Origineel geplaatst door etaoin
Vergeet niet dat buiten extra bytes er ook bytes weg kunnen vallen. MIDI-hardware garandeert niet dat alles 100% doorkomt, dus je krijgt mogelijk zelfs een nieuwe note-on terwijl je nog denkt met een oude bezig te zijn. Dus feitelijk kun je alles > 7F niet zomaar weggooien maar moet je kijken wat het is.

daar heb ik ook aan gedacht en ik denk dat er een timer nodig is, die na zeg maar 0,1 seconde de stuff weer reset als aan enkele voorwaarden niet is voldaan.
maar volgens hoefd dit zelf nog niet, want naar 3 keer lopen wordt het sowiso gereset.
en als er een nieuwe note on komt, betekent dit ook meteen dat er niet aan voorwaarden is voldaan en wordt de boel gereset.
-1 de waarde is groter is groter dan 127
-2 de byte_counter loopt op en er kan niet woorden voldaan aan de voorwaarden, dus reset.

dus kan het betekenen dat deze noot genegeerd wordt.
maar die testen die ik gedaan heb mit midiox, lijkt me dit sterk.
zelf als 2 octaven tegelijk indruk terwijl ik de sequencer knop van mijn keyboard (via emagic MT4) in en uit druk, staan de bytes allemaal netjes naast elkaar, geen enkele byte heeft een ID tag, die zegd ik hoor bij die set die je 4 bytes geleden heb ontvangen.
ik geloof best dat er een clock signal kan tussen zitten (24PQN) en misschien nog een stop byte.

en als dat het geval is, dan is er toch iets fout met je sequnecer software of de midi poort aan je pc.

twike zegd dan wel, dat je ook niet 100% op midiox kan rekenen, maar volgens mij is deze software specific voor dit doeleinde ontworpen.

En waar is de handling van de note-off? Ik zie wel een note-on met velocity van 0, maar de meeste apparaten sturen een echte note-off message. Of is deze code specifiek voor een bepaalde controller die geen note-off verstuurt?

if(byte == 0x89){ // found note off status byte for channel 10?, did we miss anything?
midi_rx_handle_note_on = 0; // reset
byte_counter = 0; // reset
}

ja, ik weet dat er ook note off berichten zijn, maar volgnes werkt deze setup wel
omdat ik met die note off eigenlijk niks doe.
omdat ik maar na de vondst van mijn WANTED data een 2ms trigger signal naar de bassdrum hoef te sturen.

corigeer me maar als ik het fout heb.

 

[etaoin]

ik geloof best dat er een clock signal kan tussen zitten (24PQN) en misschien nog een stop byte.

en vergeet Active Sensing en MTC niet.

en als dat het geval is, dan is er toch iets fout met je sequnecer software of de midi poort aan je pc.

Beide niet ondenkbaar natuurlijk, het blijft software. En bij lange kabels of brakke splitters kan het signaal ook nog eens anders aankomen dan het verzonden is.

twike zegd dan wel, dat je ook niet 100% op midiox kan rekenen, maar volgens mij is deze software specific voor dit doeleinde ontworpen.

Wat Twiki (denk ik) bedoelde is dat midi-ox niks laat zien wat ie zelf ook niet begrijpt, dus wat midi-ox in de monitor laat zien is per definitie correct binnengekomen. De foute bytes zie je niet want die heeft midi-ox onder water al afgehandeld. En je ziet het ook niet in de exacte volgorde waarin het binnenkwam, omdat midi-ox de bytes weer samenraapt zoals ze bedoeld zijn.

En nee, midi-ox is niet ontworpen als low-level midi debugger. Hij zit niet een stap hoger, op protocol-niveau.

 

[Natural_Demon]

Origineel geplaatst door etaoin
en vergeet Active Sensing en MTC niet.
Wat Twiki (denk ik) bedoelde is dat midi-ox niks laat zien wat ie zelf ook niet begrijpt, dus wat midi-ox in de monitor laat zien is per definitie correct binnengekomen. De foute bytes zie je niet want die heeft midi-ox onder water al afgehandeld. En je ziet het ook niet in de exacte volgorde waarin het binnenkwam, omdat midi-ox de bytes weer samenraapt zoals ze bedoeld zijn.

hoe dan?
het is toch serieële data!!!
als er dan een 0xf8 tussen zit, dan neem ik aan dat die byte erna, toch behoord bij die byte voor de 0xf8.
ik zou mischien nog iets met die byte_counter kunnen spelen, reseten bij de volgende byte met een waarde van minder <128 en op zoek naar de volgende, byte met een waarde van minder dan 128.

misschien is dat de methode.

 

[etaoin]

Als midi-ox een note-on binnen krijgt waar clocks en active sensing tussenin zit, laat hij die achter elkaar zien en niet door elkaar. Dat bedoelde ik met dat midi-ox dat bij elkaar raapt. Wat je in de input-monitor ziet is al opgeschoonde data. Je ziet dus niet de 'rauwe' inkomende data. Maar dat je dat niet ziet wil niet zeggen dan het er niet is.

als er dan een 0xf8 tussen zit, dan neem ik aan dat die byte erna, toch behoord bij die byte voor de 0xf8.

Dat klopt, maar het probleem zit hem ook niet in het afhandelen van correcte data, maar van alles wat niet voldoet aan wat je verwacht. En misschien heb je daar wel nooit last van, dan moet je de code laten zoals hij is.

Ik ga er zelf in mijn code altijd vanuit dat alles wat ik binnen krijg in principe rommel kan zijn, maar misschien gaat dat hier wel te ver voor wat jij wilt.

 

[Natural_Demon]

mischien is dat beter.

midi_rx_handle_note_on = 0;
midi_rx_handle_note_on_data_counter = 0;
byte_counter = 0;
/*
* Handle Received MIDI Bytes
*/
void midi_rx_byte(unsigned char byte) {
if(midi_rx_handle_note_on == 1){
if(byte_counter < 4){
if(byte < 0x80){ // we are lookking for bytes with a value smaller than 128
if(midi_rx_handle_note_on_counter == 0){ // 2nd wanted databyte
if(byte == 0x2f){ // determine note number, is the one we are looking for?
midi_rx_handle_note_on_data_counter = 1;
byte_counter++;
}
else{ // it wasn't the note we wanted, but stil smaller as 0x80, reset
reset();
}

}
if(midi_rx_handle_note_on_data_counter == 1){ // we are exspecting the 3rd byte now
if(byte < 0x80){ // determine velocity value, is the one we are looking for?
reset();
prepare_DAC(byte); // prepare dac and trigger
// or store in buffer?
// than prepare dac?
}
if(byte < 0x00){ // velocity 0 == as a noteoff message
reset();
}
else{ // it was a other value than exspected,
// what was it?,
// but we are stil searching for the velocity value.
byte_counter ++; // try til 4 time
}
}
}
if(((byte > 0x7f) && (midi_rx_handle_note_on_data_counter == 0 )||((byte > 0x7f) && (midi_rx_handle_note_on_data_counter == 1 )){
byte_counter++; //it seams we found some other data while waiting for the rest, try next byte
}
}
else{// didn't find anything usefull after several tries, reset
reset();
}
byte_counter++;
}
else{
switch(byte) {
case 0xfa: // start
cond_ctl_start();
break;
case 0xfb: // continue
cond_ctl_start();
break;
case 0xfc: // stop
cond_ctl_stop();
break;
case 0xf8: // clock
cond_ctl_clock();
break;
case 0x99: // found the sought note on status byte, channel 10 - message
midi_rx_handle_note_on = 1;
break;
case 0x89: // found the sought note off status byte, channel 10 - message
reset(); // i think not needed, byt lets do it anyway
break;
case <0x80: // found another note number before recieving the note off status byte?
midi_rx_handle_note_on = 1;//
break;
};
}
}

void reset(void){
midi_rx_handle_note_on = 0; // reset
midi_rx_handle_note_on_data_counter = 0
byte_counter = 0; // reset
}

als er nu voordat een "note off" status byte is ontvangen, weer een bye binnen komt met een waarde van minder 0x80, ga ik verder kijken of de bruikbaar is.
werkt of niet?
2 hersens denken beter als 1.



maar uh, wat vind je van het schematic?
poortA van 0-5 ging niet omdat de MCLR op A5 zit en alleen als inpoort werk.
en op poortB zit de RX in het midden.

dat zal weernadenken, tijden coderen van dat gedeelte.




beter leesbare code
http://209.35.198.6/mini_midi_mine_cv_converter.pdf

beter leesbaar schema
http://209.35.198.6/mini_midi_CV_trigger.pdf

eagle file
http://209.35.198.6/mini_midi_CV_trigger.sch

 

[Twiki]

In je software houdt je geen rekening met running status, na een note on message kun je eindeloos veel data bytes ontvangen die kleiner zijn dan 0x7F, pakketjes van 2 bytes vormen dan steeds note nummer en velocity op dat kanaal. System realtime messages die tussendoor komen worden genegeerd. De running status verandert met een nieuwe voice message of vervalt bij een system common message.

Wat etaoin zegt is een punt om rekening mee te houden, bij het opstarten van sommige apparaten wordt er onzin verzonden, kabels kunnen rot zijn, data verminkt, buffer overrun etc. Dit moet je afhandelen/negeren in je software, als je dat niet doet crasht je software om de haverklap en je komt er nooit achter wat het probleem is.

if(((byte > 0x7f) && (midi_rx_handle_note_on_data_counter == 0 )||((byte > 0x7f) && (midi_rx_handle_note_on_data_counter == 1 ))
Dit is veel overbodige code, dat kost tijd en het is de vraag of je compiler dat netjes(lees snel) oplost. Je komt bij deze code pas uit als je byte < 0x80. Dus het eerste deel van de if heb je niet nodig. Dat kan dus met een else en haakjes op de juiste plaats. En voor het tweede deel kan je schrijven if(midi_rx_handle_note_on_data_counter <= 1). (als je die variabele midi_rx_handle_etc_etc een unsigned char maakt).


Zoals ik al eerder zei, ontwerp een statemachine die alle data kan afhandelen. Dus een top down ontwerp ipv van breien in C.

 

[Natural_Demon]

hmmm,

ik kom hier uit ...

als ik een byte ontvang groter als 0x80, terwijl ik wacht op kleinere data.
althans zo zie ik het in mijn IDE.

if(byte < 0x80){ // we are lookking for bytes with a value smaller than 128
code.........
}
if(((byte > 0x7f) && (midi_rx_handle_note_on_data_counter == 0 )||((byte > 0x7f) &&(midi_rx_handle_note_on_data_counter == 1 ))){
byte_counter++; //it seams we found some other data while waiting for the rest, try next byte
}
het was dus bedoeling, als ik een byte ontanvg die groter is als 0x7f, terwijl ik op andere data wacht.

ik zou het kunnen wijzingen in

if(byte < 0x80){ // we are lookking for bytes with a value smaller than 128
code.........
}
if((byte > 0x7f) && (midi_rx_handle_note_on_data_counter == 0 )){
byte_counter++; //it seams we found some other data while waiting for the note number, try next byte
}
if((byte > 0x7f) && (midi_rx_handle_note_on_data_counter == 1 )){
byte_counter++; //it seams we found some other data while waiting for the velocity byte, try next byte
}


ik dacht toch wel dat ik ook aan de running status rekening gehouden heb.


case <0x80: // found another note number before recieving the note off status byte?
midi_rx_handle_note_on = 1;// start listening too new note numbers and velocity bytes.
break;
case 0x89: // found note off status byte, channel 10 - message
reset(); //
break;
};
p.s. staat verkeerd om in de vorige code.

en wat bedoel je met "state machine"?

maakt een quick desgn met eagle of tekening, zodat ik snap wat je bedoeld, aub.

 

[Twiki]

Er stond een fout in mijn verhaal wat ik wilde zeggen is:
Als je een variabele test of ie kleiner is dan 0x80 en het blijkt dat niet te zijn dan weet je dus dat ie groter is dan 0x7F
In C:
if(byte < 0x80)
{
doe iets
}
else
{
if(byte_counter <= 1)
byte_counter++;
}
Je kan dan dus veel weglaten.

Als midi_rx_handle_note_on_data_counter 0 is en het ook nog de goede noot is, dan volgt midi_rx_handle_note_on_data_counter = 1;
In de volgende if kijk je of midi_rx_handle_note_on_data_counter 1 is, ja dat is ie dus het nootnummer wordt ook je velocity. Was volgens mij niet de bedoeling, if moet dus else if worden.
regel 29: velocity kleiner dan 0 komt niet voor, is altijd een onzinnig statement want een unsigned char is nooit kleiner dan 0.
In heel veel gevallen verhoog bij het doorlopen van de lus de byte_counter meer dan 1x. Kan niet de bedoeling zijn
Bij je switch is de laatste regel onzin, (ik weet niet of <0x80 zelfs mag)je gaat nu iets met data doen die nergens bij horen. je wil een default met daarachter alles wat in de functie reset staat.
Runningstatus doe je niks mee, meerdere databytes achterelkaar handelt ie niet goed af, je komt ondermeer in reset terrecht.
etaoin heeft een linkje geplaatst naar wat uitleg over een statemachine. Dit is een manier om een analyse te maken van de toestanden waarin je systeem kan verkeren en hoe je overgaat van de ene toestand naar de andere. Als je er nooit mee gewerkt hebt is het misschien onhandig, maar waar ik steeds op aanstuur is dat je het probleem beter eerst op papier kan oplossen, stroomdiagram tekenen of een andere manier. Breien in software schiet niet op

 

[Natural_Demon]

Origineel geplaatst door Twiki
Er stond een fout in mijn verhaal wat ik wilde zeggen is:
Als je een variabele test of ie kleiner is dan 0x80 en het blijkt dat niet te zijn dan weet je dus dat ie groter is dan 0x7F
In C:
if(byte < 0x80)
{
doe iets
}
else
{
if(byte_counter <= 1)
byte_counter++;
}
Je kan dan dus veel weglaten.

Als midi_rx_handle_note_on_data_counter 0 is en het ook nog de goede noot is, dan volgt midi_rx_handle_note_on_data_counter = 1;
In de volgende if kijk je of midi_rx_handle_note_on_data_counter 1 is, ja dat is ie dus het nootnummer wordt ook je velocity. Was volgens mij niet de bedoeling, if moet dus else if worden.
regel 29: velocity kleiner dan 0 komt niet voor, is altijd een onzinnig statement want een unsigned char is nooit kleiner dan 0.
In heel veel gevallen verhoog bij het doorlopen van de lus de byte_counter meer dan 1x. Kan niet de bedoeling zijn
Bij je switch is de laatste regel onzin, (ik weet niet of <0x80 zelfs mag)je gaat nu iets met data doen die nergens bij horen. je wil een default met daarachter alles wat in de functie reset staat.
Runningstatus doe je niks mee, meerdere databytes achterelkaar handelt ie niet goed af, je komt ondermeer in reset terrecht.
etaoin heeft een linkje geplaatst naar wat uitleg over een statemachine. Dit is een manier om een analyse te maken van de toestanden waarin je systeem kan verkeren en hoe je overgaat van de ene toestand naar de andere. Als je er nooit mee gewerkt hebt is het misschien onhandig, maar waar ik steeds op aanstuur is dat je het probleem beter eerst op papier kan oplossen, stroomdiagram tekenen of een andere manier. Breien in software schiet niet op

hmmm, ik dacht dat ik had geantwoord.
maar goed, ik moet mijn pc ff uitzetten om ee andere te repareren.

nu weet ik weet je bedoeld, die tekening kan ik mischien beter op papier zetten, kan zijn dat je gelijk heb, maar meestal doe ik dit denkbeeldig.

in andere talen kan je wel in switch met comperators werken, in ieder geval in perl, php en c.

dat met velocity == 0, heb ik van die midi specification pagina die je me aan geraden hebt.

maar goed, ik zal nu een print plaat laten maken, met een tal leds op belangrijken pins en houd ik je wel op weer op de hoogte.

 

[Twiki]

Origineel geplaatst door Natural_Demon
in andere talen kan je wel in switch met comperators werken, in ieder geval in perl, php en c.

In c moet er een constante integer volgen

dat met velocity == 0, heb ik van die midi specification pagina die je me aan geraden hebt..

Ja velocity == 0 en niet <= 0, unsigned char is nooit kleiner dan 0.

maar goed, ik zal nu een print plaat laten maken, met een tal leds op belangrijken pins en houd ik je wel op weer op de hoogte.

Zou je het niet eerst op gaatjesprint bouwen, het is maar een klein ding, dan kom je er bijvoorbeeld achter dat je een basisweerstand mist bij een transistor.

 

[Natural_Demon]

ja, maar ik kan geen strip board regelen, alleen die boards, met allemaal losse vierkantjes.
krijg je aan de onderzijde, allemaal bobbels tussen van verbindingen van 2 or meer pins en soms vloeit de tin tussen de pin bij een ic's samen en met je stanley mesje de groef weer vrijmaken als het heel weinig tin is.
de draard verbindingen zien er dan ook *** uit omdat ergeen power en GND rails,
soms laten die kleine vierkantjes los moet je een bruggetje gaan maken en soms kun je dat onderdeelte niet verplaaatsen, moet je een op maat gemaakt draatje precies op de plaats laten vallen tot het volgend vierkantje en hopen dat het niet verschuift zodra je in de buurt komt met de soldeerbout
ik heb ook een proto board, maar daar blijven de ic's niet op vast zitten, grrr.
allemaal van het merk REPRO.
ik heb het geprodeerd, het ligt hier voor me.

voor een PSU, een pic met enkele ledjes,fijn,
maar voor iets groters met meer als 1 ic vind ik het maar ***.

ik zet gewoon extra gaatjes in het eagle design, zo er iets fout zijn, dan kan ik altijd nog netjes bruggetjes maken en spoortje door snijden...
vertinde boarden met silkscreen solderen zich beter.
maar ik zou niet weten wat er fout aan is.
dat midi-in circuit gedeelte is gewoon van de xoxbox met een 6n139 en de rest is mijn.

ik ben hier gekomen om te kijken of dingen zijn beter kunnen dat ik het plan.

 

[Twiki]

Origineel geplaatst door Natural_Demon
dat midi-in circuit gedeelte is gewoon van de xoxbox met een 6n139 en de rest is mijn.

Q4?

 

[Natural_Demon]

sorry, met de late reactie, ik had al 2 x geschreven en gedacht dat ik al geantwoord had, schijnbaar toch niet gedaan.
haha, i.e. venster ergens achterin geraakt en per ongeluk alles gesloten terwijl ..

met q4 wi ik een .... nabootsen.
de pic wordt niet te belasten met het gevraagde vermogen van het drum ciuit en ik kan
eventueel nog een pot/trim meter inbouwen en kan ik met spanning gaan spelen van de trigger.

q2 werkt wel, heb ik al gebouwd in een matrix switchboard setup.
belast de led de pic niet.
1 transistoren weerstand mer boiet met niet op het board.

 

[Twiki]

Q4 mist de basisweerstand, daar ging het toch over???