Bassman

Oh great, goyousalukis, if you don't have any I can get one and send it to you. Really grateful for your help. you're welcome to call or text me on 209 471 7039 thanks again.

Hi, I'm in California but I'm happy to pay for the chip and any postage needed. Bassman

Does anyone know where I can get a replacement pre-programmed PIC18F452? I had an accident with my Core8 board and need one. It does not need to be new, or maybe someone can burn the bootloader for me as I can get the Microchip easily enough? Thanks bassman

Hi damiano, Thought I would reply as you have not had any help here. Easy method: Just turn on the Midi Merge in the Midibox64 and the Midibox will forward the notes on to the PC. So you just need to send the same note data that the Midibox sent. Fancy Method: If you want to remote control the buttons on your Midibox64 via Midi (which may be pointless if the easy method works out), read the file mios_tables.inc. Here you create the Midi events that will trigger the buttons. e.g. MIOS_MPROC_EVENT_TABLE ;; entry 0x00-0x0f (button Numbers) MT_ENTRY 0x9b, 0x00 ;; C -2 Button #1 MT_ENTRY 0x9b, 0x01 ;; C#-2 Button #2 MT_ENTRY 0x9b, 0x02 ;; D -2 Button #3 MT_ENTRY 0x9b, 0x03 ;; D#-2 Button #4 MT_ENTRY 0x9b, 0x04 ;; E -2 Button #5 MT_ENTRY 0x9b, 0x05 ;; F -2 Button #6 etc. That's not really difficult, but you will have to write some code into the main.asm file for the function USER_MPROC_NotifyFoundEvent at line 468. As an example I use this to toggle the buttons everytime a note on is received, rather than have Note On events holding on for ages until the Note Off (or Note On Vel 0) is received. It's a little crude but it works. USER_MPROC_NotifyFoundEvent movff MIOS_PARAMETER2, MIOS_PARAMETER1 ;; Put MIOS_PARAMETER1 into MIOS_PARAMETER2 (Note number) movf MIOS_PARAMETER3, W ;; Get Note velocity for switch skpz ;; If zero (Note Off) skip next command and just toggle it to be 1 movlw 0x01 ;; If >0 Make it 1 and toggle it to be 0 (pressed) xorlw 0x01 ;; Toggle it movwf MIOS_PARAMETER2 ;; Save it in MIOS_PARAMETER2 goto MB64_BUTTON_Handler ;; Activate the button and exit! Then you will have to re-assemble the code and send it into your Midibox using MIOS Studio. Anyway, surely sending the same Midi event, as the Midibox sent to your PC, from the second Midi device, into the Midibox with the Merge on will be the simplest thing to do. good luck Bassman

It varies, depending on parts and how busy. Just study the list of orders and how far down the list you are, that's the best way. Or send him a message and ask. He's a first class person and it's a miracle he get's all the order out, he works very hard for us all. bassman

I think the simpler Meta Event solution, though you do say you have it working now, is this single Meta Event. MB64E_META_Handler_00 ;; this example sends a SysEx string: F0 7f 00 06 vv F7 ;; Button set to Meta Event, ;; 1st parameter 00 (Meta Event 00) ;; 2nd parameter vv (mmc function Stop 01, Play 02, FFwd 03, Rewd 04, Rec 05 etc) call MIOS_MIDI_BeginStream ; begin stream movlw 0xf0 ; send 0xf0 call MIOS_MIDI_TxBufferPut movlw 0x7f ; send 0x7f call MIOS_MIDI_TxBufferPut movlw 0x00 ; send 0x00 call MIOS_MIDI_TxBufferPut movlw 0x06 ; send 0x06 call MIOS_MIDI_TxBufferPut movf MIDI_EVNT_VALUE, W ; send button value, stored in MIDI_EVNT_VALUE call MIOS_MIDI_TxBufferPut movlw 0xf7 ; send 0xf7 call MIOS_MIDI_TxBufferPut goto MIOS_MIDI_BeginStream ; end stream and exit This way, you can have as many MMC buttons as you want, just by making any button a Meta Event, parameter 1 - 00, and parameter 2 - the MMC command number. I'm thinking about the Shuttle problem, it's more complex. bassman

I don't know what application you are using, but this is the way I did it in the MB64. In the file mb64_buttons.inc, around line 237, I changed the routine to this. MB64_BUTTON_OnOnly ;; when on: send button value defined in dump ;; when off: send nothing BRA_IFSET TMP1, 0, ACCESS, MB64_BUTTON_NotifyChangeEnd ;; turn off SR4 8 LEDs SET_BSR MB64_BUTTON_VALUES_SR0+3 setf MB64_BUTTON_VALUES_SR0+3 ;; save status of button rcall MB64_BUTTON_Hlp_SaveStat rgoto MB64_BUTTON_Send The shift registers that you want to affect is determined by the two lines, I wanted to use sr4. SET_BSR MB64_BUTTON_VALUES_SR0+3 setf MB64_BUTTON_VALUES_SR0+3 So in your case you want to affect sr1, so the two lines would look like this SET_BSR MB64_BUTTON_VALUES_SR0+0 setf MB64_BUTTON_VALUES_SR0+0 You can affect more than 1 shift register, by adding the two lines again, for every shift register you want to affect. For example; SET_BSR MB64_BUTTON_VALUES_SR0+0 setf MB64_BUTTON_VALUES_SR0+0 SET_BSR MB64_BUTTON_VALUES_SR0+1 setf MB64_BUTTON_VALUES_SR0+1 SET_BSR MB64_BUTTON_VALUES_SR0+2 setf MB64_BUTTON_VALUES_SR0+2 SET_BSR MB64_BUTTON_VALUES_SR0+3 setf MB64_BUTTON_VALUES_SR0+3 That would do all 4 shift registers. Bassman

Yes, you are right. And the DOUT will respond the same. bassman

Of course you can use a simple contact. Piano wire is good for making your own spring wire. Really the problem is figuring a way to mount whatever you are going to use, micro switches or simple contact wire. You don't want the connecting wires to connect to moving parts i.e. the pedals themselves, as the constant movement will quickly break the wire. bassman

Oh sorry, I didn't know that the Guinness World Record people were the bastions of definitions. ;) I wonder why they chose Jazz Music for their contest? But I see you are in the 'descriptive definition' camp. Good luck with that! :) Anyway I deliberately didn't use the word 'rests'. bassman

I would like to add to this discussion, by saying that there is no definition of music. There have been many attempts by composers, musicians, philisophers and laypeople. No definitions have met with any acceptance. Some may argue that at least it is sound. This is not the case, as in between the sounds are silences which are as much part of the 'music' as the sound(s). There does not have to be more than one sound (see plainsong), there does not have to be any sound (as in the score to a musical work that has never been played). This has led to the modernists, like Cage, pushing the boundaries, as if they are doing something new. But the point is, music is entirely subjective, as is all art, so that the statement "the definition of music", does not even satisfy the definition of the word 'definition'. There are two types of definitions: A descriptive definition provides to a term a meaning which is in general use. A stipulative definition of a term carries a meaning which a speaker wants it to convey for the purpose of his or her discourse. Thus, the term may be new, or a stipulative definition may prescribe a new meaning to a term which is already in use. A descriptive definition can be shown to be "right" or "wrong" by comparison to usage, but a stipulative definition cannot. Neither type of definition is satisfactory in this instance, and would raise an argument when an attempt is made to associate one or the other type with music, so that the debate about 'the definition of music' would never get started. Clearly, music cannot be defined. Hey, but it's fun trying! bassman

That seems quite right. Yeah, converting them to 8n NOTE OFF events has it's advantages. I know, you're quite right, but when you have the chance, try monitoring the pitch bend events from different manufacturers. It's scary, (especially the 'big guys'). Well, of course, but there are definately (though only small) differences in implementations. Especially between Yamaha and Roland who seem to want to compete for 'leadership' in the MIDI.org bassman

Well, I may be wrong, but it seems like only a small amendment is needed. This is the MIDIO128 code that does the converting. It's the first part of the midi scan within the MIDIO_MIDI_NotifyReceivedEvent routine, after a check is done for an All Notes Off CC. MIDIO_MIDI_Scan ;; if note Off event has been received, convert it to Note On with velocity == 0 movf MIOS_PARAMETER1, W andlw 0xf0 movwf TMP2 xorlw 0x80 bnz MIDIO_MIDI_Scan_NoNoteOff MIDIO_MIDI_Scan_NoteOff movlw 0x90 iorwf MIOS_PARAMETER1, F clrf MIOS_PARAMETER3 MIDIO_MIDI_Scan_NoNoteOff It then goes on to check ;; set TMP5[0] if the second byte shouldn't be checked; this is the ;; case for: ;; o Channel Pressure ;; o Pitch Bend and ;; set TMP5[1] if the value is located in second, and not in third byte ;; this is the case for: ;; o Program Change ;; o Channel Pressure and ;; if program change branch depending on MIDIO_CFG0_ALT_PROGCHNG then goes on to scan the DOUTs and then prepare a DIN Event and then Send it. It seems that if the start of the MIDIO_MIDI_Scan looked like this instead, then the conversion would not be done, and everything else would appear to be ok. MIDIO_MIDI_Scan ;These lines need to stay movf MIOS_PARAMETER1, W andlw 0xf0 movwf TMP2 MIDIO_MIDI_Scan_NoNoteOff But it seems too simple, so I'm probably wrong. bassman

Yes I see that, but this is all 'under the circumstances' which, to me is not the best solution. As it stands, parsing all the midi in status bytes to be 9n, in case an editor has made them 8n, will work, obviously. But........we're giving up a whole midi command with 128 numbers! Maybe 8n status should be implemented properly, rather than being 'not supported'. It's original function may be lost in the 'forgotten world since synths began', but it is very useful. It, quite rightly provides a velocity, or sensitvity, for releasing a note. Many instruments are affected by this, Piano, reeds, percussion, vibraphone and anything with a damper etc. Even organs can have a nice 'chuff' effect when simulating the wind in the pipes being shut off. Now this may not be of interest to many in this beat box era, (which is ok too), but even from a 'techy' point of view, that's another 128 numbers we can use for control. Isn't that useful? Suppose you had a vintage keyboard that only sent 8n, you could have DOUT pins that ONLY that keyboard could control, if you didn't have the conversion to 9n. Or one core could send 8n and another 9n. They would both work perfectly as notes, but you would have some more control specific to one or the other. Just because everyone's doing the 9n thing now, doesn't mean we can't make use of both. bassman

Stryd, I don't personally think that's the best solution. Some old midi gear only works with 8n status, so it needs to be there for those. LyleHaze, [tt]an on/off control handled by 0-127 would be <64=OFF, >63=ON.[/tt] This is ok for controllers that are strictly ON/Off such as Sustain Pedal. Even so, not all manufacturers have adhered to that, there are some that have implemented as 0=off >0=ON. Other controllers have a range 0-127 (0-7f H) and some like pan would be centered at 64 (40 H). There's no general rule here. Pitchbend has been implemented differently too. Some manufacturers have used 64 & 0 (40 & 00 H) for center and sent true 14 bit messages, many have 64 & 64 (40 & 40 H) as center and increment/decrement both bytes equally. According to midi.org ; [tt]Pitch Wheel Change. 0mmmmmmm This message is sent to indicate a change in the pitch wheel. The pitch wheel is measured by a fourteen bit value. Center (no pitch change) is 2000H. Sensitivity is a function of the transmitter. (llllll) are the least significant 7 bits. (mmmmmm) are the most significant 7 bits. [/tt]. They claim 2000H as center. They all seem to work though. Try running various brands pitchbends through midiox and you'll see. Then, there's what midibox actually does with midi. If we're looking an overall 'rule', we're not going to find it. Just because midi.org set themselves up as the 'midi standard' creators, doesn't mean everyone follows that. Some think their way is best and want to be rebels. Sound familiar? ;) bassman

Probably this thread will have TK thinking about adding a few more notes by now. Tk is the name and it's up to him to make alterations even in the documentation, though we all know he's busy, but nonetheless, we are not at liberty to make changes. But maybe between us we can do a full document for the Wiki all about using Midi In to trigger events. I suspect it's not used much, but it has many useful aspects to it, especially when there are more than 1 core and one of them is mainly used for a master controller, as I expect you do with organ setups. It gets a little confusing with 3 byte events other than NOTE ON Vel. 0 or >0. For controllers, mostly v=0 would be off, but not all of them. Poly Aftertouch seems ok with v=0 being off. Pitchbend would not be right for v=0 to be off. Even though it is a 3 byte event, it differs from the others in that it is EX vv1 vv2, a 14bit data send. The documentation shows it as E0 7f vv, but that is to make the editor just use a 0-7f value to keep things constant through out the app., though it is converted into a 14 bit message in the app. ;; sending three bytes (7bit converted to 14bit)MIDI_EVNT_Send_Ex ; Pitch Bend movff MIDI_EVNT0, WREG call MIOS_MIDI_TxBufferPut SET_BSR MIDI_EVNT0 movlw 0x00 BRA_IFCLR MIDI_EVNT_VALUE, 6, BANKED, MIDI_EVNT_Send_ExLow rlf MIDI_EVNT_VALUE, W, BANKED andlw 0x7e MIDI_EVNT_Send_ExLow call MIOS_MIDI_TxBufferPut movff MIDI_EVNT_VALUE, WREG andlw 0x7f call MIOS_MIDI_TxBufferPut rgoto MIDI_EVNT_Send_End So vv1=64 & vv2=64 would be considered off (ie. center). I don't know if this one is worth using for midi in control to the DOUT, it would only go off when you pitch bent fully down, (well...it might have a use). The DOUT is just a switch and will turn off at 0 and on at anything >0 (I'm not sure here)? So maybe it's only good for midi events where that is appropriate. Having said that, there's no reason why the inventive use of midi to get what one wants, needs to be ristricted. I don't see much discussion about it, seems like some experimenting, and then a document, might encourage people to make more us of it? Lastly, re: the DOUT comments, they're not in the .ini file (at least not mine) so I'm not sure about that. Also what about the relay.ini file? And the midio_presets.inc, have you tried editing this? bassman

It's possible, as all .ini files can be edited. TK made it that way for flexibilty. Perhaps TK might nameise an amendement to the code documentation to make it clearer. ################################################################################ # The MIDI_IN and MIDI_OUT sections include all settings for the IO pins # ################################################################################ # Syntax for a MIDI IN entry (MIDI event controls output pin): # <pin-number> = <byte 0> <byte 1> # # The maximum allowed number of output pins is 128 # # Supported MIDI events (. stands for hex digit, vv stands for 00 or 7F) # 9. .. (Note On) Example: 90 30 (MIDIO128 receives 90 30 vv) # A. .. (Poly Aftertouch) Example: A0 30 (MIDIO128 receives A0 30 vv) # B. .. (Controller) Example: B0 07 (MIDIO128 receives B0 07 vv) # C. .. (Program Change) Example: C0 30 (MIDIbox receives C0 30) # D. .. (Channel Aftertouch) Example: D0 30 (MIDIbox receives D0 30) # E. .. (Pitch Bender) Example: E0 7F (MIDIbox receives E0 7F vv) # # - On 2-byte events (C. and D.), the output pins just toggle (0->1 or 1->0) ################################################################################ # Syntax for a MIDI OUT entry (input pin triggers MIDI event): # <pin-number> = <ON byte 0> <ON byte 1> <ON byte2> <OFF byte 0> <OFF byte 1> <OFF byte2> # # The maximum allowed number of input pins is 128 # # Supported MIDI events # (Note On) Example: 90 30 7F 90 30 00 @OnOff (ON: send 90 30 7F, OFF: send 90 30 00) # (Poly Aftertouch) Example: A0 30 7F A0 30 00 @OnOff (ON: send A0 30 7F, OFF: send A0 30 00) # (Controller) Example: B0 07 7F B0 07 00 @OnOff (ON: send B0 07 7F, OFF: send B0 07 00) # (Program Change) Example: C0 01 00 FF 00 00 @OnOff (ON: send C0 01, OFF: send nothing!) # (Channel Aftertouch) Example: D0 40 00 FF 00 00 @OnOff (ON: send D0 40, OFF: send nothing!) # (Pitch Bender) Example: E0 30 30 E0 60 60 @OnOff (ON: send E0 30 30, OFF: send E0 60 60) # # Also valid: # (Note On/Off) Example: 90 30 7F 80 30 00 @OnOff (ON: send 90 30 7F, OFF: send 80 30 00) # (Controller Fun) Example: B0 10 40 B0 11 40 @OnOff (ON: send B0 10 40, OFF: send B0 11 40) # # - If byte0 is FF, the event will not be sent # # Supported button behaviours (see MIDIbox tutorial): # @OnOff # @OnOnly # @Toggle # ################################################################################ This part maybe could read something like; # Also valid, but not recomended as Note Off is NOT a supported Midi In Event: # (Note On/Off) Example: 90 30 7F 80 30 00 @OnOff (ON: send 90 30 7F, OFF: send 80 30 00) Either way, the information IS there, though perhaps not conspicious by it's absence, Note Off is not supported for Midi In. bassman

That is exactly the way I see it, Jim. The code you found is quite self explanatory. And TK cleared up what I was suspecting in MIOS. I thought it best to point those, who need to know how to edit their .ini files, away from using NOTE OFF and save them from any possible puzzle. bassman

Yes you're right Per S, I was more concerned with what MIOS does with 'running status' and got mixed up. It seems that 'running status' messages are converted to 'full midi' messages by having their status bytes added on before re-sending. Thanks TK, for clearing that up. Anyway, no-one is suggesting NOTE OFF is obsolete. It's perfectly valid. However, if you use incoming midi to trigger events, it would be prudent not to use NOTE OFF messages for this, as most of the applications convert this to NOTE ON vel. 0, so when the app. searches for a match with NOTE OFF, it probably won't find it. At least the situation is clear now, and there shouldn't be any trouble whatever messages are used. bassman

Well ok, Per S, you can get NOTE OFF to happen by editing the .ini file to deliberately send NOTE OFF. I didn't really mean that you can't get it to happen. However, MIDIO128 will convert incoming NOTE OFF status bytes to NOTE ON velocity 0. So try merging your core through another core, using the Midi In Merge. You'll find your NOTE OFF have gone, they'll be NOTE ON. Plus, if you ever want to use midi input to trigger events by using 'Forward Input to Output', and decide to use Note on/off messages, you'll find that MIDIO128, after converting incoming NOTE OFF status bytes to NOTE ON velocity 0, will not find a match in your MIDIO Presets. The MIDIO128 .ini file clearly shows NOTE OFF (80 NN VV) as not supported for midi in. I'm not sure it's a good idea to use NOTE OFF anymore, especially just because it looks neat when monitored. Sooner or later, there'll be trouble, mainly for those that my original post was trying to help. But, of course, some older (and maybe more desirable) equipment may well work better with NOTE OFF being sent. bassman

Amendment duly noted, Jim. Midibox does not send 80 NN VV (NOTE OFF), but if it receives it, it is converted into a NOTE ON with velocity 0. However I see no sign of any use of 'running status' to transmit or accounting for receiving 'running status' events. I'm not sure if 'running status' bytes are merged and re-sent. I would suggest, that users needing to use the Merge function and/or the Midi In for remote, should look in the item that is sending, to see if 'running status' can be turned off somewhere. I think, the code looks like it should ignore midi events that do not have their status bytes first. Just my opinion from looking through the relevant code, quickly. Probably TK can enlighten us further! bassman

The NOTE OFF is still used in older gear, and you can still use it now, so it's not obselete. But when 'RUNNING STATUS' came in around '91, NOTE ON with Velocity zero started, as it allowed the same status byte to be used (or rather omitted in running status). Running Status allows the status bit to be left out and just the note number and velocity to be sent. A different status byte would interupt running status. It allowed more data transmission to be squeezed out of the midi baud rate. If you are just using a keyboard and a module or two, it's of no real consequence, but if you use computer software such as Cubase, Cakewalk etc, and have 8 midi ports and 20 sound modules playing away, you'll appreciate the advantage. Access to official midi specifications is freely available at www.midi.org bassman

ok, done that, yet another syntax to figure out, standardisation is boring! ;D I put it in About : References : Midi http://www.midibox.org/dokuwiki/simple_midi_specification bassman

I amended, with your suggestion re: status byte. Quite right. I would paste it to the wiki, if I could figure out how. I have it ready to paste. Oh... there's 'technobabble' aplenty at www.midi.org. :D Hopefully, it will help some, I see the question often enough, maybe it'll be a few less replies for stryd, I notice he's always answering that one. Amazing how many people don't understand midi! I also found this cool page from Univ. NSW australia. http://www.phys.unsw.edu.au/jw/notes.html might be useful for the wiki too? bassman

Visit www.midi.org for the full spec but it's all in binary. Here's an explanation in hex, as that's what's used by midibox. Also, what I call a 'Command', Midibox refers to as the 'Status byte". I think 'Command' makes things more understandable. MIDI Commands in HEX All Midi commands are higher than 7f Hex (127 decimal, 01111111 binary). They start with 80 Hex (128 decimal, 10000000 binary), which means that a command always has bit 7 set (10000000 binary)and the associated values that follow the command do not have bit 7 set (011111111 binary). This is how midi primarily distinguishes between commands and data. You don't need to know that to edit the .ini files. The first byte of all midi commands is divided into the command half and the midi channel half. NOTE OFF (still in use for older gear mainly, now most devices use NOTE ON with velocity = 0 instead) 8X NN VV 8 is the command half for a NOTE OFF X is the midi channel half - range 0-F (0-15 decimal) NN is the NOTE NUMBER - range 00-7F (0-127 decimal) VV is the notes VELOCITY - range 00-7f (0-127 decimal) NOTE ON 9X NN VV 9 is the command half for a NOTE ON X is the midi channel half - range 0-F (0-15 decimal) NN is the NOTE NUMBER - range 00-7F (0-127 decimal) VV is the notes VELOCITY - range 00-7f (0-127 decimal) (VELOCITY vaue 0 (zero) is now used for NOTE OFF) POLYPHONIC PRESSURE (some call it AFTERTOUCH) AX NN VV A is the command half for a POLYPHONIC AFTERTOUCH X is the midi channel half - range 0-F (0-15 decimal) NN is the NOTE NUMBER - range 00-7F (0-127 decimal) VV is the AFTERTOUCH AMOUNT - range 00-7f (0-127 decimal) CONTINUOUS CONTROLLER (CC for short) BX CC 7F B is the command half for a CONTINUOUS CONTROLLER X is the midi channel half - range 0-F (0-15 decimal) CC is the CONTROLLER NUMBER - range 00-7F (0-127 decimal) VV is the CONTROLLER AMOUNT - range 00-7f (0-127 decimal) PROGRAM CHANGE CX PP C is the command half for a PROGRAM CHANGE X is the midi channel half - range 0-F (0-15 decimal) PP is the PROGRAM NUMBER - range 00-7F (0-127 decimal) CHANNEL PRESSURE (some call it AFTER-TOUCH) DX VV D is the command half for a CHANNEL AFTERTOUCH X is the midi channel half - range 0-F (0-15 decimal) VV is the AFTERTOUCH AMOUNT - range 00-7f (0-127 decimal) Note : Thorsten comments the use of this midi command as 3 bytes. "D. .. .. (Channel Aftertouch) Example: D0 30 7F @OnOff (MIDIbox sends D0 30 vv)" This might cause problems with some gear as it should be 2 bytes. There should be no note associated with this command. It affects all notes being held down on the same midi channel. PITCH BEND EX B1 B2 E is the command half for a PITCH BEND X is the midi channel half - range 0-F (0-15 decimal) B1 is the first half of the PITCHBEND AMOUNT - range 00-7F (0-127 decimal) (refered to as the least significant byte) B2 is the second half of the PITCHBEND AMOUNT - range 00-7F (0-127 decimal) (refered to as the most significant byte) Note: when B1 and B2 are both 40 hex (64 decimal), that is centered, no pitchbend. Note: Thorsten works this out for you in the firmware, so just use range 0-7F (0-127 decimal) There are more midi commands, but this should help get you started. bassman