TK.

No, the firmware can "only" handle up to 5 inputs and up to 5 outputs (it's already magic for such a small Atmel device!) You will need 4 x GM5 for your usecase Best Regards, Thorsten.

Wait until I will install SL as well ;) As a workaround I've already a simple command line tool under preparation which natively accesses the MIDI ports and doesn't require Java. It's less comfortable to use (ok, for me it's much more comfortable than clicking with the mouse), but doesn't depend on the OS version... Best Regards, Thorsten.

Seems that nobody understands me anymore the last days ;) Read this: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Ftools%2Fmk_syx%2FREADME.txt And read the comments in the config file again: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Ftools%2Fmk_syx%2Fmidibox64e.ini For Reaktor configuration, this wiki page could be interesting for you: http://www.midibox.org/dokuwiki/doku.php?id=reaktor Best Regards, Thorsten.

Thats ok for me! Go for special bulk orders in Brazil. Best Regards, Thorsten.

Yes, you only need to change the LED patterns. 32 patterns are available for each LED ring mode - they are prepared for 2 DOUT SRs per default, but you could easily change them so that only the 8 rightmost bits are used. Change has either to be done in the source code: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox64e%2Fsrc%2Fmb64e_presets.inc Or in your midibox64e.ini file, which can be converted to .syx, and uploaded via MIDI-Ox (or similar SysEx tools) once the application is running (for changing the setup w/o recompiling the source code): http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Ftools%2Fmk_syx%2Fmidibox64e.ini If they are sending relative values, the received absolute value of the same CC number will be displayed. This has to be supported by your host application (e.g. it works fine with Reaktor) - if the host doesn't send back the absolute position as a MIDI event, LED rings only make sense in absolute mode. Best Regards, Thorsten.

By destroying J1 and J2 you will get "110" as resulting configuration -> "I only". This matches with your observations. For your usecase, there was no need to remove the bridges - "000" was fine for 5 inputs and 5 outputs, and with two modules you would get 10 inputs and 10 outputs - like intended? Best Regards, Thorsten.

Thats a really clever idea! In the pre-computer era musicians reserved a track of their multi channel tape to playback the clock signal, with this AU you bring the same method to modern DAWs. Unbelievable, that nobody did this before! :) Do you think that a mode would be possible which sends a different clock pulse level for the Start signal? (I consider to write a MIDIbox application which generates a MIDI clock/start from the audio signal) Would higher resolutions like 192ppqn and 384ppqn be possible as well? And would it be possible to add an optional negative delay? This would allow to compensate the latency if the audio of the synched device is sampled by the DAW and forwarded to the Aux bus. Best Regards, Thorsten.

Hi Trevor, yes, there is a workaround: MIOS32 Device ID 0x09 will be mapped to MIDIO Device ID 1 MIOS32 Device ID 0x0a will be mapped to MIDIO Device ID 2 MIOS32 Device ID 0x0b will be mapped to MIDIO Device ID 3 MIOS32 Device ID 0x0c will be mapped to MIDIO Device ID 4 I hope that it will work, because I never tried this. Best Regards, Thorsten.

Yes, this will work! :) The LED stages of the LTC module are nothing else than two monoflops - you can connect any digital source to LTC::J1:MI and LTC::J1:MO Best Regards, Thorsten.

The technical term for such a mechanism is "force-to-scale" or "harmonizer" The application which perfectly matches with your requirements is AC Sensorizer: http://www.midibox.org/dokuwiki/doku.php?id=acsensorizer_04 There are also videos which show how it works Best Regards, Thorsten.

No, unfortunately a PIC18F4685 won't work as it has less RAM than the PIC18F4620. Best Regards, Thorsten.

I haven't tried this yet, but it will only cost me a weekend... Most of the required functions are already prepared (e.g. scanning directories, reading configuration files, reading/writing SysEx files...) - I don't see a reason why it shouldn't work. However, I guess that documenting and releasing MIOS32 has higher priority? Best Regards, Thorsten.

Interesting find! The firmware already provides this mechanism (-> the Phase control allows to set/clear the test bit with a defined delay in the range of 1..255 uS in steps of 1 uS - exactly like if you would insert NOPs into the C64 code). All I need to do is to remove the noise lock protection (means: removing two assembly instructions which I included for your own comfort). And the best: since the phase parameter can control all 3 oscillators, more special sound variants can be generated compared to Wave Composer, which nobody have heard before ;) Best Regards, Thorsten.

Song mode: just read the manual of V3 - it's sufficient, nothing will be changed here. News: you could follow the log of this SVN directory http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2F The firmware is already in use by two friends and myself. All new features are working perfectly - no bugs so far, only unimplemented minor features which I don't find so important. Best Regards, Thorsten.

Could you please try Ploytec driver v1.0.6 instead of v1.0.7? It can be downloaded from this page: http://www.ucapps.de/mbhp_usb_gm5.html Best Regards, Thorsten.

Ja, mit wenigen Anpassungen in main.c wird das funktionieren. Statt CCs sendet man einfach Pitch Bender Events, und die VU Meter Werte erhaelt man als Channel Aftertouch Events Gruss, Thorsten.

Alright ;) (although I'm experienced with HDL design, the usage of FPGAs wouldn't be an option for my hobby project) Best Regards, Thorsten.

You could use MIOS_LCD_YAddressSet to adapt the offset. Best Regards, Thorsten.

What kind of MIDI events should be sent? So long the Note/CC number doesn't matter (as you can configure the routing in Ableton Live anyhow), you could use the ain64_din128_dout128 application without any changes. MB64 is only relevant for people who want to control MIDI hardware directly w/o using a computer. Best Regards, Thorsten.

I'm definitely interested on the results. I already did some plannings for MBSID V3 where similar update rates will be possible. What I found as a limiting factor is the bus interface of the SID, as the write/chip select input has to be strobed synchronous to the SID clock (= 1 MHz) to avoid sporadical effects like multiple gate triggers (especially bad if the ADSR workaround is applied) or crackling sounds on frequency/pulse width/filter sweeps. Such a requirement means, that it won't be possible to update more than 8..10 SID registers per scan cycle - did you already consider this and/or found a better solution (e.g. additional hardware) to ensure synchronous timings? dsPICs are a good choice for this kind of usecase. :) Best Regards, Thorsten.

Interesting! Could you please share some MP3s to give us an impression? How did you solve the problem of an accurate 1V/oct conversion, are you using an external 16bit ADC? And what is the sample rate, how many CV inputs are available? Best Regards, Thorsten.

Of course, if it is possible to create a unique byte value from the 2^(3*7) = 2^21 bit range, than a hash function is a practicable solution. But it will be less flexible, as you have to adapt the calculation of the hash value whenever new value sequences have to be parsed (no problem for you, as the sent MIDI events of your keyboard are known and won't be changed) It would be different if you would use a 32bit controller (like MBHP_CORE_STM32 :)), because here it doesn't matter if the hash is 8bit, 16bit, 32bit - in any case the CPU will need the same time to compare the value. For 8bit controllers it means that comparing values with range >8bit is very *very* expensive, since many instructions have to be executed to get the complete result. Accordingly, your coding strategy has to consider such limitations. Btw.: a binary tree search would also be an option, but a good solution would use a code generator (resp. parse tree generator) as well. Best Regards, Thorsten.

I would prefer method 1 due to the better overview. But I wouldn't start the search for a matching sequence once all three values have been received, instead I would do this on-the-fly whenever a new MIDI event has been received to improve the realtime responsiveness of the application. Just use a single table which contains the three values + a pointer to the function which should be called in each line. Something like this: const my_search_structure_t search_structure[] = { // BC LSB MSB PC Function { 0x00, 0x70, 0x01, &DoThisFunction }, { 0x00, 0x44, 0x05, &DoThatFunction }, }; [/code] Strategy: - when the first event (BC MSB) is received, search for the first member in the table with matching MSB number - when the second event (BC LSB) is received, check if the second value is matching as well, if not search for any of the following members with matching MSB/LSB number - same when PC is received. First check for matching PC, and if it doesn't match search for the next matching MSB/LSB/PC element. - finally you should know the member which is completely matching, so that the function can be called A way to speed up the search would be a sorted table (something you can do manually, especially because the table structure doesn't change during runtime), so that your algorithm can break the search once the incoming number is lower/higher than the value of the current structure member. And a way to speed up the search even more: set a threshold for the starting point. E.g. 64 (or any number which is in the middle of the search values in the first column). This allows you set the optimal starting point for the search. Alternatively to method 2: you could program a code generator (e.g. based on a small perl script) which generates the parser based on a human readable table. But I'm not sure, if it would run faster (on the PIC) compared to the table search method I mentioned above. Warning: there is a typical programming error in your code: [code] switch state { case 0: //no bytes received so far // ... case 1: //0x00 received there is no break before "case 1", accordingly case 0 will execute the code after case 1 as well (same for other case statements) Best Regards, Thorsten.

The link is already in the Wiki: http://www.midibox.org/dokuwiki/doku.php?id=midi_specification I prefer to use the web.archive link since I know that it will exist permanently ;) Best Regards, Thorsten.

Great selfmade case and PCBs (?) :) What kind of encoder are you using? I never saw an encoder in such a white plastic package before. Best Regards, Thorsten.