TK.

...and I assumed, that you are building your own DSP based synths meanwhile? :) Looking forward for the pictures! Best Regards, Thorsten.

The problem is, that you need to specifiy DOS style pathes (with backslash) in the configuration files. For "make" there is the same requirement, and in addition all DOS make implementations I know ignore the PATH variable, so that tools need to be specified with absolute pathes. Accordingly, the Makefile* looks very different. At least these were the issues which prevented me from setting up the common Makefile approach for the SDCC wrapper, and why I decided to create a simple makefile generator which allows to create a batch file. I'm not really a DOS/Windows fan (in fact I work under Solaris/Linux @ Work, and mostly under MacOS @ Home), but I find it important to provide an universal solution, so that everybody is able to contribute, and not only a small group of people who have the right OS installed. We already have this issue with MPASM (which runs only under Windows), please don't do the same error like me with a new approach. Best Regards, Thorsten.

I selected the GPL at a time where MIDIbox was in a primitive state, giving other people the possibility to jump on the train and to continue with my initial work. Some years later I realized, that I spent an immense effort into the projects, but nearly nobody really contributed to the source code (*). Instead of that, sometimes low experienced people were trying to sell ready made MIDIboxes, completely based on my IP, over different channels to make profit without contributing in any way to the community (even not supporting the customers?) I think it is my right to switch to another the license if I changed my mind based on such experiences, and I also think that I don't need to justify my own learning process. Meanwhile there are other powerful open projects for MIDI (or DAW control) like Arduino or Monome which have been developed by multiple persons and distrubuted under Creative Commons license. So, if somebody prefers such a license, just jump on there and help to support these communities. Best Regards, Thorsten. (*) this has changed, meanwhile people have contributed new software and hardware projects, even tough MIOS is not licensed under GPL anymore. So, it seems that the decision wasn't bad for the progress...

Yes, thats the way how I normaly create libraries - it's the most effective way. You can do this if you have the time, but please do it in a way which allows to rebuild the library on a simple way without the need for installing a massive tool chain. So, rebuilding a .lib file should even work under Windows without installing Cygwin (or another unix environment) I would use a perl based makefile generator for this, which creates a .bat file (for windows) and a Makefile (for unix) based on an ordered list of all sources. Once the functions have been extracted, there is no need to re-do this process. So, first check if it is faster to do the extraction by hand (I would estimate an effort of about 15 minutes), or writing a script which you will probably only use one time, and never again ;-) All you need is a powerful text editor (IMHO) Best Regards, Thorsten.

Currently the MIDI IN ports of all core modules are linked together, but they could also be connected to individual MIDI Out ports. For such a case, just remove the J11 connections between the cores, and stuff all core modules with an optocoupler. Best Regards, Thorsten.

Under MacOS, you can use Osculator for this (http://www.osculator.net/wiki/). Problem with OSC: if a small microcontroller like the PIC should receive a lot of UDP messages in a short time, there is a certain chance for data loss. Therefore the RTP (or alternatively TCP/IP) approach is slower, but more reliable. Best Regards, Thorsten.

No, it doesn't look like a PIC Best Regards, Thorsten.

Yes, it would be possible to split the MIOS functions over different .o files instead of using a single kernel, but it's a different approach and leads to disadvantages. I already evaluated the micro-kernel approach ca. 2 years ago, there are so many dependencies between the modules, that a seperation leads to a higher memory consumption that we currently have if all MIOS functions are included in a static kernel (e.g. you have to isolate internal variables, e.g. by using a stack, and you have to use the 4-byte instructions "goto" and "call" more often than the 2-byte instructions "rgoto" and "rcall"). It's also more difficult to provide MIOS updates to users who are less experienced with programming like you (don't know, how many users really know how to recompile an application, especially when they have to use so many different tools). However, if I would design MIOS today, I would consider this from the beginning, especially because it would free some extra memory for applications which don't use a graphical display or motorfaders (functions which are only used by a small number of applications). I would also define the function interface SDCC like so that an assembly file conversion, which changes the FSR pointers, wouldn't be required anymore. But I don't plan to do this for MIOS V1, accordingly you don't need to try this out again - it would be wasted effort... Splitting the wrapper functions over different files makes sense, I would split them all. Best Regards, Thorsten.

It seems that it is using the standard USB-MIDI driver, so the firmware is probably buggy. I would open the case and check, if a PIC has been used - if so, I could give you an alternative firmware which works ;-) Best Regards, Thorsten.

What is the reason why you are not using seperate keyboard splitzones? Best Regards, Thorsten.

Hi Doug! :) The LED functions can be changed in the LED map (I'm not sure how you've changed the configuration - if you've used the mk_syx.pl script, see the midibox64.ini file) I just have noticed that the comments in midibox64.ini are wrong. Value 9 displays External Bank 1-8, Value 10 External Bank 9-16 The map is also located in mb64_presets.inc for the case that you want to change the source code directly. Best Regards, Thorsten.

At least it is possible to forward Key->CV within the modulation matrix. It shouldn't be so complicated to add a K2A (Key-to-AOUT) option as well (ca. 10 lines of code). It could also forward the gate, e.g. of the first oscillator, and the glide flag. The only reason why I haven't added this yet is, that I want to collect the requirements before adding such a feature. This should ensure that the implementation is universal enough... however, your requirements are still more simple than expected. Any other functions required? ;-) Best Regards, Thorsten.

Forget about just remaking existing clones - the analog TB303-like hardware can be controlled via AOUT module with the MBSID V2 firmware. Think about the powerful possibilities (modulation and trigger matrix, arpeggiator, wavetables, etc...). It's even possible to sequence an additional SID in parallel to a TB303 from a single core and from the same CS. Or add more cores to sequence even more SIDs or external synth hardware... So, the basics already exist, new software doesn't need to be developed, just start with the experiments... Best Regards, Thorsten.

Yes, I would also propose to use the integrated shift register handling of MIOS, it is *much* faster, and there are many C examples for the usage (see bottom of http://www.ucapps.de/mios_c.html) In addition, it makes sense to play a little with the examples in order to get a feeling about the programming model. What I'm missing in your C code is the initialisation of the IO pins at J5. By default these are analog pins, in order to enable the digital stage, following value has to be written into ADCON1: ADCON1 = 0x07; In addition, I would propose to set the pins directly on the following way: LATAbits.RA0 = 1; and LATAbits.RA0 = 0; This will result into a single instruction. The currently used "BITASSIGN" macro will probably generate 10 instructions or more Anyhow, as mentioned above: try some programming examples first, and especially consider the usage of the natively supported SRIO chain Best Regards, Thorsten.

I find this approach nice. I considered to use autoconf as well at the beginning, but found it complicated and not flexible enough for different operation systems. E.g., under Windows a Cygwin installation is required, but I fear that a normal MIDIbox user is already overloaded enough by installing perl/SDCC and GPASM :-/ Therefore I started the simple "perl makefile generator" approach. However, this shouldn't prevent you to start with a more proper setup of the SDCC skeleton! Feel free to enhance it in future, but please also understand that I will continue to maintain the "simple solution". Best Regards, Thorsten. P.S.: converting the wrapper to a shared library is an elegant idea, on the other hand: is the linker able to ignore (not link in) the code which isn't used by the project? Here I see the only benefit of a library

Yes, MIDI-to-COM runs at 38200 baud, it's a baudrate which most PCs can handle. Merging MIDI data: first the hint, that you won't be able to run the UART with different baudrates for Rx and Tx port. So, you either need a 8051 derivative with second UART, or an external UART like MBHP_IIC_MIDI (the most flexible solution, as it especially simplifies merging). The approach behind merging MIDI streams: the receiver needs to block the main task (which generates MIDI data internally) whenever a MIDI event is received. An event consists of 2 or 3 bytes, for coding see the MIDI spec. Only exception is a SysEx stream, which starts with F0 and ends with F7... The MIDI protocol allows to omit the first byte (status byte) if it is identical to the previous one. This is called "running status. Your handler needs to take care about this, otherwise it could hang up as less bytes are received than expected. A status byte is indicated by bit #7 Another exception are the realtime events 0xf8..0xff - they don't change the running status, and can even be received in between a MIDI event. It makes sense to add a timeout handler, which breaks when a MIDI event hasn't been completely received within a certain time (200 mS is a good value) Best Regards, Thorsten.

What is the name of your MIDI Interface? Best Regards, Thorsten.

yes, therefore it has been removed from my website. Please remove it from your webserver as well Best Regards, Thorsten.

You can download project_mbseq.hex of http://www.ucapps.de/mios/midibox_lc_v2_0_alpha1.zip into the MIDIbox SEQ, this will give you a full featured Mackie Control Emulation. Best Regards, Thorsten.

I already own some ENC28J60 samples, and I'm planning to play with them in some weeks. A Swissonic MIDI-USB interface (available at Thomann) will cost you 20 EUR, and I'm sure that the usage is less troublesome than doing experiments with Ethernet. Other people probably will need an ethernet switch if they want to connect something else to the ethernet line. It's the same like adding an USB hub... accordingly I don't see an ethernet interface as a solution for saving one USB port. Could you please search for a driver, which is *already* available for MacOS, Windows and Linux? I saw a lot of solutions (ideally I would use RTP MIDI, but it seems that a driver is only available for MacOSX), but nothing which could really universal enough for a MIDIbox project. In distance to MIDI over IP, OSC is pretty easy to realize - it can use UDP packages to transfer informations. Such packages can be sent with a TCP/IP stack like uIP (http://www.sics.se/~adam/uip/index.php/Main_Page) Best Regards, Thorsten.

Hallo Juergen, in der PIC18F Version ist dieses Feature in MIOS integriert. Du kannst es bspw. mit MIOS Studio ausprobieren (-> Debug Window, erste Seite). Im MIDI Out Window siehst Du dann auch den entsprechenden SysEx-String Gruss, Thorsten.

Schade, ich habe heimlich auf einen Praezedenzfall fuer Leitungsreflexionen gehofft ;-) Gruss, Thorsten.

Hallo, das wird so nicht stabil funktionieren, der Retry-Mechanismus, wie er auf der MBHP_IIC_MIDI Seite gezeigt wird (IIC_MIDI_Send() Funktion) ist sehr wichtig, ansonsten koennen Daten verloren gehen, falls die CPU schneller sendet als das IIC Modul ueber die MIDI Leitung uebertragen kann. IIC laeuft ja mit 400 kbit, und MIDI mit nur 31.25 kbit -> Flaschenhals-Problem) Um eine Note zu uebertragen, muesstest der Master Start, 0x10, 0x09, 0x93, 0x3c, 0x7f, Stop senden 0x10: Slave ID 0x09: Type "Note" 0x93: oberes Nibble: nochmals Note, unteres Nibble: MIDI-Kanal 4 0x3c: Notenwert (hier: C-4) 0x7f: Velocity Der Slave antwortet meistens mit einem ACK. Doch wenn er mal keine Daten mehr annehmen kann (Datenstau), antwortet er stattdessen mit NAK. Der Master muss den Transfer dann mit einem Stop/Start solange neu aufsetzen, bis der Slave wieder ACK sendet. Es gibt eine Demo-Applikation (midi_router Projekt), doch ich befuerchte, dass sie die Sache nicht verstaendlicher macht, zumal hier die Uebertragungsroutine in Assembler geschrieben ist. Gruss, Thorsten.

Tach auch, Du koenntest einen Schrumpfschlauch ueber das andere Widerstands-Beinchen ziehen, und es dann an J2:Vd anschliessen. Statt Schlauch gibt es auch andere Moeglichkeiten zum isolieren, zur Not hilft Tesa. Loete einfach die vier Datenleitungen D0..D3 am LCD ab, und isoliere die offenen Enden, bspw. mit Tesa Gruss, Thorsten.

MIDIbox CV V1.2 is now available for download New Features: Support for AOUT_NG module Support for BankStick (128 Patches can be stored) Interpolation function which allows to smooth 7bit controllers (CC/velocity/...) over 12bit resolution with selectable slew rate Legato/Mono/Poly now selectable seperately for each channel main page now displays patch number, patch name and 8 animated (short-triggered) activity meters there is now a DIN sync start/stop output available at pin C.1 (CORE::J7:SC) the DIN sync clock output is now located at pin C.0 by default (CORE::J7:RC, consistent with MBSEQ) ChangeLog: http://www.ucapps.de/midibox_cv_changelog.html Updated User Manual: http://www.ucapps.de/midibox_cv.html Download: http://www.ucapps.de/mios_download.html Have fun! :) Best Regards, Thorsten.