robin303 Posted September 7, 2004 Report Share Posted September 7, 2004 I was wondering if it's possible to change the Global Midi Channel with a meta-event, (attached to a potmeter with range 0 to F). I tried this, but it doesn't work :( MB64_META_Handler_08 ;; Change global midi channel to MIDI_EVNT_VALUE from potmeter [00-0F]. movf MIDI_EVNT_VALUE, W movwf MB64_GLOBAL_CHANNEL And the call to the metaevent: 48 = F0 08 [00-0f] "Change chnl" DECPerhaps my thinking is way to simple, hey I'm just starting with this assembly stuff ;D Quote Link to comment Share on other sites More sharing options...
TK. Posted September 7, 2004 Report Share Posted September 7, 2004 MB64_GLOBAL_CHANNEL is located above 0x7f, therefore you've to select the high-byte of the address with SET_BSRE.g. movf MIDI_EVNT_VALUE, W SET_BSR MB64_GLOBAL_CHANNEL movwf MB64_GLOBAL_CHANNEL, BANKED or: movff MIDI_EVNT_VALUE, MB64_GLOBAL_CHANNEL see also:http://www.ucapps.de/mios/mios_ram_handling.txtBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
robin303 Posted September 9, 2004 Author Report Share Posted September 9, 2004 Okay thanks, now I understand this!However, implementing the example code does not work! When I turn the potmeter to which I assigned the meta event, the display 'garbles' and everything goes crazy :-/I guess it's not as easy as just moving a new value into MB64_GLOBAL_CHANNEL?I even tried this: MB64_META_Handler_08 ;; Change global midi channel to MIDI_EVNT_VALUE from potmeter [00-0F]. movff MIDI_EVNT_VALUE, MB64_GLOBAL_CHANNEL goto MB64_DUMP_RestorePotButtonEvents Quote Link to comment Share on other sites More sharing options...
TK. Posted September 9, 2004 Report Share Posted September 9, 2004 Anything is really strange with your setup. I remember the Autorepeat problem, which was also not explainable. I've no idea...Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
robin303 Posted September 10, 2004 Author Report Share Posted September 10, 2004 Well hows this :DIt seems that the error was in the fact that I tweaked the MidiOx "delay after F7" setting up a bit, to 350 ms. :P Yeah, yeah I know, call me impatient!This seems to work perfectly for the small .SYX configuration uploads. Uploading the MidiBox app with this speed however, is obviously not a good idea. The strange part is that I get no time-outs during the upload operation, and MIOS is rebooting as usual after the program upload. Anyway, I downgraded the setting back to 750 ms and now the upload obviously succeeded because your example code is now working like a charm, Thorsten! Quote Link to comment Share on other sites More sharing options...
TK. Posted September 10, 2004 Report Share Posted September 10, 2004 I knew that it must be such an error ;-)MIOS cannot send a time out when it's deactivated during the flash erase/programming procedure. During this time no code is executed - therefore no reaction.Could you please also try to upload the code via sysexbox?http://www.midibox.org/mios_tools/sysexbox_18f_v1_0c.zipBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
robin303 Posted September 10, 2004 Author Report Share Posted September 10, 2004 Yes it's a stupid mistake. I just didn't think about this parameter change that I did in MidiOx. Like I said, for .SYX updates, 350ms works perfectly fine. Weird huh ???I tried the latest version of sysexbox and it worked perfectly for MidiBox program upload and for a settings.syx upload. ;D 8)However, the 'request dump - mios program memory' feature doesn't give much feedback. I know something is happening because my send and receive leds are burning for a while. But then the Leds go out and the status tells me only 1 block was received (1.184 kb). On the bright side, requesting banks seems to work OK!Is there any way to convert the requested bank data back to a text file format? Quote Link to comment Share on other sites More sharing options...
TK. Posted September 10, 2004 Report Share Posted September 10, 2004 Like I said, for .SYX updates, 350ms works perfectly fine. yes, because MIOS is so intelligent that it only erases/reprograms flash and EEPROM pages which have been changed. If there are only a small number of changes, the procedure runs through much faster.I tried the latest version of sysexbox and it worked perfectly for MidiBox program upload and for a settings.syx upload. ;D 8)nice to hear :)However, the 'request dump - mios program memory' feature doesn't give much feedback. I know something is happening because my send and receive leds are burning for a while. But then the Leds go out and the status tells me only 1 block was received (1.184 kb). which MIDI interface are you using? it would be interesting if other people notice the same problems.On the bright side, requesting banks seems to work OK!thats strange, because it's the same type of data... (also the data block size is the same)Is there any way to convert the requested bank data back to a text file format?yes, you can do this with the syx2asm.pl script, which can be found in the tools/ directory of the MIOS package.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
TK. Posted September 10, 2004 Report Share Posted September 10, 2004 P.S.: if you don't mean the MIOS BankStick Request, but the MIDIbox64E Bank Request: no, there is no perl script for this, but vmidibox64e will get the same SysEx transfer functions, and this appliation already supports the possibility to export a .ini fileBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
robin303 Posted September 10, 2004 Author Report Share Posted September 10, 2004 I am using a Midiman Midisport 2x2.Requesting Mios Program memory returns 1 block (1184 bytes) then crashes (hangs) my box and -after a while- reboots my box automatically.Requesting a 32k or a 64k bankstick dump crashes my midibox. It reboots after about 1 minute.Requesting Mios EEPROM memory makes my box reboot as well. Requesting a midibox64 bank works perfect. 8 blocks, 2120 bytes.I'm sorry for the weird results but that's the status :'(I did the tests several times, restarting both sysexbox and my midibox quite some times. Quote Link to comment Share on other sites More sharing options...
TK. Posted September 10, 2004 Report Share Posted September 10, 2004 I am using a Midiman Midisport 2x2.I've tested the software with the same interface (latest m-audio drivers)Requesting Mios Program memory returns 1 block (1184 bytes) then crashes (hangs) my box and -after a while- reboots my box automatically.Requesting a 32k or a 64k bankstick dump crashes my midibox. It reboots after about 1 minute.Requesting Mios EEPROM memory makes my box reboot as well. a MIOS program/EEPROM/BankStick download request always reboots the MIDIbox after all blocks have been sent. The reboot is required, since the data encoding algorithm needs some memory which is normaly reserved for the application.You are writing that this happens after some time. This indicates that all blocks are sent (32k BankStick e.g. 32 blocks)The midisport 2x2 is a multiclient capable interface, this means that you can open sysexbox and midi-ox at the same time. Please do this and check if MIDI-Ox receives all the blocks.Are you using the v1.0c release of sysexbox? Older versions used a smaller MIDI In buffer which can cause problems (seems that this depends on the Windows version...)Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
robin303 Posted September 10, 2004 Author Report Share Posted September 10, 2004 Yes Thorsten, you are right. After opening MidiOx I have verified that all is being received correctly. The 'hanging' meant that the midibox was not responding to anything anymore. But obviously it was busy sending data.I am using the 1.0c release of sysexbox.So I would suggest you make some kind of 'busy' flag in sysexbox, so that one can see that's it's still working. And maybe you can take a look at the 'bytes received' and 'blocks received' fields, because here they don't reflect the actual amount of data sent. That's pretty confusing.For the rest of it, great software! ;D Quote Link to comment Share on other sites More sharing options...
robin303 Posted September 10, 2004 Author Report Share Posted September 10, 2004 Oh by the way. With the Global Channel thing (that's what this topic was for :)) ....I want to display the channel change in the display once I turn the potmeter. So I made this: ;; -------------------------------------------------------------------------- MB64_META_GLBCHN_CHANGED_L1 STRING 16, 0x00, " Global Channel " MB64_META_GLBCHN_CHANGED_L2 STRING 16, 0x40, " Changed To " MB64_META_Handler_08 ;; Change global midi channel to MIDI_EVNT_VALUE from potmeter [00-0F]. movff MIDI_EVNT_VALUE, MB64_GLOBAL_CHANNEL call MIOS_LCD_Clear TABLE_ADDR MB64_META_GLBCHN_CHANGED_L1 call MIOS_LCD_PrintMessage call MIOS_LCD_PrintMessage ;; set cursor movlw 0x4C call MIOS_LCD_CursorSet movf MIDI_EVNT_VALUE, W call MIOS_LCD_PrintChar return Now I have two problems:1. Printing the value MIDI_EVNT_VALUE, the display does not show me the channel number but a vertical bar graphic.2. When I turn the potmeter to quicly, I can only see my message for 1/10 of a second. Because the normal display page is stealing the focus back. Can I override this behaviour and make my message the 'boss' for two seconds? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.