TK.

[table][tr] [td][/td] [td][br]Ha-Ha![br]Nils and Stryd are Slow-Pot-Movers![/td][/tr][/table]

Yes, the new behaviour is better for live performance. Best Regards, Thorsten.

Thank you! The device will be detected now by the installation software after I changed the product ID (so that it matches with the .inf file), but the driver fails, probably because the I'm using different endpoints. Therfore I need more informations (which are given by usbview - Sasha: if you find the time... :)) Cimo: under Linux you can request the complete descriptors the following way. First type "lsusb" to display connected USB devices - example: # lsusb Bus 001 Device 003: ID 046d:c016 Logitech, Inc. M-UV69a Optical Wheel Mouse Bus 001 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 002 Device 002: ID 0a92:1001 EGO SYStems, Inc. Bus 002 Device 001: ID 0000:0000 [/code] Thereafter request the descriptors of the "EGO SYStems" device the following way: [code] # lsusb -v -d 0a92: Bus 002 Device 002: ID 0a92:1001 EGO SYStems, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0a92 EGO SYStems, Inc. idProduct 0x1001 bcdDevice 1.01 iManufacturer 1 iProduct 2 iSerial 4 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 101 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 3 bmAttributes 0x80 MaxPower 32mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 2 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 9 bInCollection 1 baInterfaceNr( 0) 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 1 Audio bInterfaceSubClass 3 MIDI Streaming bInterfaceProtocol 0 iInterface 2 MIDIStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 65 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 1 Embedded bJackID 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 2 External bJackID 2 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 1 Embedded bJackID 3 bNrInputPins 1 baSourceID( 0) 2 BaSourcePin( 0) 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 2 External bJackID 4 bNrInputPins 1 baSourceID( 0) 1 BaSourcePin( 0) 1 iJack 0 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 1 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 3 Best Regards, Thorsten.

VID and PID are not sufficient - the driver doesn't find the device. I need to know more details - they can be determined with USBview (a Microsoft utility) which can be downloaded from here http://www.ftdichip.com/Resources/Utilities/usbview.zip (and various other locations) Important: enable Options->Config Descriptors and Options->Location IDs Thereafter File->Refresh (or press F5) Search the MIDI device in the USB tree, and post the content of the information window as in this example: Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x40 (64) idVendor: 0x0A92 idProduct: 0x1000 bcdDevice: 0x0001 iManufacturer: 0x01 0x0409: "Thorsten Klose" iProduct: 0x02 0x0409: "MBHP USB" 0x0409: "MBHP USB" iSerialNumber: 0x00 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x03 Open Pipes: 2 Endpoint Descriptor: bEndpointAddress: 0x02 Transfer Type: Bulk wMaxPacketSize: 0x0008 (8) wInterval: 0x0000 bSyncAddress: 0x00 Endpoint Descriptor: bEndpointAddress: 0x82 Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) wInterval: 0x0000 bSyncAddress: 0x00 Configuration Descriptor: wTotalLength: 0x0053 bNumInterfaces: 0x01 bConfigurationValue: 0x01 iConfiguration: 0x03 0x0409: "T.Klose MBHP USB" bmAttributes: 0x80 (Bus Powered ) MaxPower: 0x10 (32 Ma) Interface Descriptor: bInterfaceNumber: 0x00 bAlternateSetting: 0x00 bNumEndpoints: 0x02 bInterfaceClass: 0x01 (Audio) bInterfaceSubClass: 0x03 (MIDI Streaming) bInterfaceProtocol: 0x00 iInterface: 0x02 0x0409: "MBHP USB" 0x0409: "MBHP USB" Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x07 07 24 00 00 01 41 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x06 06 24 02 01 01 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x06 06 24 02 02 02 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x09 09 24 03 01 03 01 02 01 00 Unknown Descriptor: bDescriptorType: 0x24 bLength: 0x09 09 24 03 02 04 01 01 01 00 Endpoint Descriptor: bEndpointAddress: 0x02 Transfer Type: Bulk wMaxPacketSize: 0x0008 (8) wInterval: 0x0000 bSyncAddress: 0x00 Unknown Descriptor: bDescriptorType: 0x25 bLength: 0x05 05 25 01 01 01 Endpoint Descriptor: bEndpointAddress: 0x82 Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) wInterval: 0x0000 bSyncAddress: 0x00 Unknown Descriptor: bDescriptorType: 0x25 bLength: 0x05 05 25 01 01 03 [/code] Best Regards, Thorsten.

Great! :) Please inform me once the dummy guide is avalable, so that I can add a link from the MIDIO128 page - It will be really helpful :) Best Regards, Thorsten.

A prepared IDE is the perfect choice for doing the first steps. Especially for people who just want to customize a header file, rebuild and upload the .hex file. To remind you: thats 99% of all MIDIbox users, and we should focus on them instead of a minority of programmers who will find their way anyhow. It could be part of MIOS Studio, or (which would go into another direction) a completely prepared Eclipse setup, which seems to be popular these days. Of course, files can always be edited outside the IDE, thats normaly the way I'm doing, even when I'm using IDEs for other microcontrollers. But whenever I explore a new micro family (and I did this often in the past), I prefer to setup a project with a simple frontend tool before going deeper into the topic - just because it's much faster and less error-prone (especially when you get direct access to help pages for each particular parameter and option). The HiTOP IDE (which I mentioned before) doesn't install a complete Cygwin environment, instead it uses the cygwin1.dll (POSIX emulation library, 1.2 MB). I'm not sure about the licensing here, but it seems to be a way to call unix commands within a unix-style file system. Best Regards, Thorsten.

Thanks for voting! I changed the encoder speed handling in RC16 - it works much better now! :) Best Regards, Thorsten.

Unfortunately it isn't possible to hold the notes like in non-superpolyphonic mode, since the voice handler needs to be reseted on any patch change. Thereafore notes are now always released in superpoly mode (changed in RC16) Best Regards, Thorsten.

RC16 is now available - beside of bugfixes for minor issues, you get: o "ENV Misc" layer added for MB6582 Control Surface o SIDPlayer: lower line now always cleared when new LCD message is sent by host o changed encoder speed behaviour: values incremented fast by default now. Incrementer is slowed down by pressing the SHIFT button (previously it was the opposite behaviour) [/code] Best Regards, Thorsten.

I find this project very attractive, it could be used as MBSEQ extension, as MBLC motorfader replacement, MB64E encoder/LEDring replacement etc... I guess that it will be a lot of fun working with it, therefore I would like to purchase two kits (without Arduino hardware) once you are starting the order. :) Best Regards, Thorsten.

Sidenote: here an example for a quite successful development platform for hobbyists. Arduino provides a single package which contains everything: IDE with editor and code upload tool, compiler, code library, a lot of templates: http://www.arduino.cc/en/Main/Software. Check also, how other users release new code modules. Everything is open source, so nobody needs to re-invent the wheel, an adaption of the IDE to MIOS could be possible. I must say that this is the direction I would prefer for MIOS: within an extremely short learning period you are able to do modifications in existing templates and upload the code. Ah - even they are also using their own makefile generator, such an environment could hide the autoconf process very easily (the user wouldn't regognize it ;-)) Best Regards, Thorsten.

Sasha, could you please determine the vendor and product ID of your cable? (called VID and PID in device manager) I would like to check, if the same driver is working with MBHP_USB_PIC Best Regards, Thorsten.

Hi Steve, please keep me informed about the progress Best Regards, Thorsten.

I've the feeling, that it would be better to change the encoder handling, so that they are in "fast mode" by default, and slow down while the SHIFT button is pressed. Especially for high resolution values like CutOff this would mean, that the whole value range can be sweeped with a single move w/o using the SHIFT button. Nobody has complained about the current behaviour yet, therefore it would be interesting for me if you agree (-> use the poll function of this article) Best Regards, Thorsten.

yes, this is the right one. Page is mirrored now Best Regards, Thorsten.

Concerning the usability evaluation: I would propose a two-step approach: first ask two or three programmers of User Projects to migrate their source code, thereafter ask common users (in the MIDIbox news section) to rebuild the applications (it isn't required to own the appr. hardware) Goal of the evaluation should be to find out, how much support people need to install and troubleshoot the toolchain, and how long it does take to get the setup ready for rebuilding an application. Please highlight in the announcements, that we are not searching for hackers who are already familar with Unix environments. As it was your idea to go for such an approach, you have to lead this evaluation pro-active. Best Regards, Thorsten.

The MIOS_LCD_PrintCString function of the updated MIOS wrapper is now able to handle strings located in code and RAM So, a special function is not required anymore. :) Best Regards, Thorsten.

There is a new skeleton release available in the http://www.ucapps.de/mios_download.html section . Changes: - enhancement of MIOS_LCD_PrintCString: now it can also print strings which are located in RAM The appr. function in mios_wrapper.asm and the declaration in cmios.h has been changed ("code" attribute removed) - updated latest MIOS header files - mkmk.pl enhancements (based on discussions with Ditier): source code can be located in subdirectories, and libraries can be created SDCC compatibility: I've tested my own applications with 2.7.0, and they are working fine. Therefore I recomment the usage of this SDCC release instead of 2.5.0 (reminder: 2.6.0 was too buggy) Migration: Since there are no bugfixes, a migration of your application is only required if you want to use the new features. However, due to consistency reasons it makes sense to release application updates with the new wrapper in future. Following steps are required: 1) copy the files of the tool directory into the tool directory of your application 2) copy the files of the mios_wrapper directory into the mios_wrapper directory of your application. Beware: unfortunately mios_tables.inc is still located there (could change in future) - don't overwrite this file, or make a backup and copy over your customized version 3) copy the new cmios.h into your application directory If you've added libsdcc.lib to your project, and want to use SDCC 2.7.0 in future, please update this library as well. A precompiled version is available at http://www.ucapps.de/mios/mios_libsdcc_v2_7_0.zip Creating a library Nice usecase for the new mkmk.pl feature is libsdcc, which has to be rebuilt for MIOS due to the changed FSR pointer mapping. Have a look into the README.txt and MAKEFILE.SPEC file of the library package mentioned above. Best Regards, Thorsten.

Hi Ciaran, before uploading the MIDIO128 configuration file, you have to install the MIDIO128 application - you will find the package at the MIOS upload page. It seems that this approach (installing MIOS -> MIDIO128 -> configuration) isn't so obvious, therefore I will add this info to the MIDIO128 introduction page soon Best Regards, Thorsten.

Hi Didier, Yes, thats the drawback when complete source packages are released. On the other hand I can give users simple instructions how to update the MIOS wrapper. They only need to know, how to copy files from one into another directory. E.g., each MIOS release contains a migration/ directory with files which can be copied over the original files of a release package. By concept they are always downward compatible. In your approach, the user has to install a new MIOS library package. Thats similar, it has some other advantages, but also disadvantages (risk that some additional files or code libraries are released, which are not compatible with the application - bad if the user faces such issues again before the maintainer has tested a new library release with his hardware), but I think that we don't need to discuss this again - it would really be endless ;-) The next processor family used in MBHP is probably a 32bit microcontroller, either ARM or TriCore based. Regardless of which device is finally used, the code base has to be completely overworked. Re-use of existing files won't be possible - the trouble starts already with SDCC incompatibilities to gcc (e.g. structures, word alignments), assembly code, but also general conceptional topics. E.g., for a future OS I would like to include sophisticated interrupt handling, and multitasking capabilities (or I could be on a free OS like FREERTOS, or maybe Linux?). The programming style will be totally different (and hopefully easier) Accordingly it would be required to setup a new software platform - with a totally different structure. It wouldn't make much sense anymore to provide MIOS as a single kernel, also the bootloader wouldn't exist anymore (MIDI is too slow to transfer huge memory dumps). The whole firmware would be uploaded on a single run, probably via JTAG. The point is: for such a platform change I would prefer the usage of an existing toolchain, maybe even on an existing IDE for people, who want to spend some money for powerful debugging tools (and you really need such tools once you are starting to work with foreign sources). It could be structured totally different from yours. E.g., I evaluated HiTOP in the past, it generates Unix compatible Makefiles and uses Cygwin in background under Windows which will please you (as it means: the source code origanisation and build process is Unix compatible) But this just as an example - it could also look totally different in some years (once I'm doing the platform change...) depending on what is available at this time. If a powerful non-commercial toolchain is available until then, I would prefer such a solution instead of a (low-cost) commercial environment of course! So, you know the requirements: generating a simple DOS batch file - this is not possible with autoconf, but it's also obsolete as you can completely work with Unix tools once Cygwin has been installed. Your argument is, that it's easy for Windows people to install the additionally required tools. My argument is, that it will increase the complexity too much, including the installation of more files on the computer (can take a long time if somebody only has only a low-bandwith connection to internet (modem)), and learning how to use the bash shell instead of doubleclicking a .bat file But before discussing in circles again: some Windows guys - not only programmers, but especially "common users" - should try out your approach and report their experiences. Not really ;-) Nice gimmick, but nobody would try to build a dedicated PIC18F4685 application for PIC18F452 - and if he doing this, he will notice very quickly that some SFRs are not available during build time. The presence of headers doesn't need to be checked if all sources are part of a release package (and the maintainer ensured, that a rebuilt is possible), and preprocessor symbols can currently be easily included from the MAKEFILE.SPEC (-D...) Some C compiler features were unstable in the past (see bug tracking), it's dangerous to allow such a flexibility - you will notice this once you are debugging code anomalies like I did in the past. same can be defined in MAKEFILE.SPEC The release package which contains all sources is per concept ready for distribution (ok, "make clean" before zipping it makes sense) ...so far somebody writes documentation... Moving the platform into a direction which makes it only understandable for an elitary circle of Unix geeks? Maybe I see it too much black-white, I would like to hear the oppinions of other programmers and especially users - if they still follow this thread ;-) Best Regards, Thorsten. P.S.: I did the changes in the makefile generator this morning, and going to do some compatibility checks with SDCC 2.7.0, which I was planning for a long time... seems that the imperfections of 2.6.0 have been fixed! :)

Hi Didier, Nobody asked for library releases yet... Some of the modules could be put into a library, some others not since they are using constant definitions to customize the code. I don't like different approaches for different usecases. In addition, I would prefer that all source files which are required to rebuild an application are part of the release package. Therfore a good starting point would be a wiki page which collects all code modules, that are already available (there are a lot, but most of them are not so nicely documented like your CAN library). MIOS: was always downward compatible in the past, you can still run applications which have been programmed and compiled for earlier versions with the latest MIOS version Processor: within the PIC18F family, there are not so many processors which are qualified for MIOS due to available peripheral functions and packages. All of these processors are compatible to PIC18F452, only the available memory differs. Ok, there is one exception: the PIC18F4685 (and similar CAN derivatives) has a memory window between 0x60..0x7f which is not directly accesible. But if somebody wants to use a PIC18F452 application on a PIC18F4685, he only has to change a single line in the default linker script. This is a question of how good such a change is documented. Such a manual change would even be required in your approach, if a local linker file has been used in the project (e.g. for larger arrays) Or did I overlook something? Why haven't you just asked me for an extension in the makefile generator instead of setting up a new flow which will cause additional efforts at other sides? I will add this possibility to the next skeleton release. Here again: why haven't you just asked me to add such a feature? It doesn't take much time for me to add such a function, especially if I find it useful as well - it will be primitive, but I can ensure that it will work sufficient enough for Unix and DOS. Please also accept that I'm trying to keep things simple enough. There are flaws in your concept, and they can only be solved by adding even more complexity (tools and configuration options). Partly these are issues which went into my own decitions in the past, and which lead to the setup as it is. I fear that your proposals complicate the whole flow too much for a project, which is mainly intended for people who like to make music, and who mostly don't have the technical background like IT guys. I'm disappointed that your contributions will only be released for your own approach, but I guess that this shouldn't prevent others to try the same, time will show if it works successfull. What I take from this debate: - there is the need to define (sub)directories in the mkmk.pl script - it should be possible to generate a Makefile for a library - consider to provide the wrapper as a precompiled library (*) - there is still no page which collects all code module contributions (*) here I could profit from your work: did you already found a way to define the stack pointers outside the library? Concerning the two tables in mios_tables.inc: I noticed that you defined them in the main.c file - I would prefer following approach: put a mios_mproc_event_table.o and mios_enc_pin_table.o file into the library. These objects should contain the default table content. Then add "extern" references to these tables into cmios.h This opens following possibilities: the tables will be preloaded correctly with default entries, taken from the library, whenever there is no .o file with *the same name* in the local scope during linking. Accordingly, the programmer is able customize the tables within his project by copying the .asm file(s) from the library source directory into his own project, doing the required modifications and compiling them locally. Best Regards, Thorsten.

Some users of MBHP_USB and MBHP_USB_PIC interface have reported this issue in the past - it is related to the definition of the AC (Audio Control) interface. It seems, that this causes a problem with some Windows installations. I haven't started some more investigations, but just provide an alternative firmware without the AC definitions (see http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip, usbdsc.c) Note that my descriptors could be slightly different from the ones used in the MIDINator firmware (I haven't compared them) Yes, absolutely. Could you please try if my own PIC based implementation works better with your host? Note that it requires the USB bootloader, which is provided by Microchip (it simplifies the firmware upload). Therefore my firmware begins at 0x800. Beside of try&error: not really. :-/ Best Regards, Thorsten.

thats correct. yes, no problem. The two gates of the AOUT module are only useful if somebody has built this module into a breakout box (so that the module can be plugged to different MIDIboxes) - and if he doesn't need more than 2 gates. AOUT_LC and AOUT_NG users have to use the 8 gate pins at J5 anyhow. Best Regards, Thorsten.

Hi, the loopback test is a special firmware which cannot be uploaded via MIDI, it replaces the bootloader and therefore is only useful for somebody who owns a PIC burner. However, although the bootloader refuses to upload this firmware... the messages are looking good! The block between 0x3000..0x30ff (the only one outside bootloader range) has been uploaded successfully. This means, that the bidirectional connection is working. Before uploading MIDIO128, you have to upload MIOS v1.9f (can be found in the mios_v1_9f_update package within the pic18f452/midi directory) Best Regards, Thorsten.

After MPLAB has been installed, you will find the "MPASMWIN" application in the installation tree which allows you to build a .hex file without using the IDE. So, just edit the files of the midibox release package with your favourite text editor (don't rename the files), and assemble the code like described here: http://www.ucapps.de/howto_tools_mpasm.html. For MIDIbox64 it means: assemble main.asm - it's always this toplevel file, it includes all the .inc files. Thereafter upload the new main.hex file with MIOS Studio. The .ini file (probably you mean the one of the mk_syx package) is part of the bank configuration. It can be changed and converted to a .syx, thereafter uploaded to the MIDIbox64 during runtime. However, this is part of the "configuration layer" - the firmware has to run for beeing able to receive this configuration data. Best Regards, Thorsten. P.S.: ah yes - happy new year! :)