TK.

Hi, there are already some FAQs in the MIDIbox Wiki (-> http://wiki.midibox.org, I strongly suggest to use this platform, because it guarantees that other people can help you to enhance your work Best Regards, Thorsten.

Did you really upload the original .syx again, or do you assume this from your first try? I'm asking just to ensure that you made this important test. Update: I just noticed that setup_mbseq_v2.asm contains the right table. So, changes have to be made there. You could try the main.syx file --- this is my own setup, where DETENTED2 is already set for all encoders (only the datawheel is set to DETENTED since I'm using another encoder here) I don't know which type is required for the bourns encoders. It could also be that you've to swap the pins Best Regards, Thorsten.

Hi, I've no explanation why this simple change should lead to such an effect, so we maybe have to search the root cause step-by-step. Could you please upload the old .syx again in order to check if this is still working? Thereafter undo your changes in the mios_tables.inc file, build a new .syx and try it out --- if the LCD gives out garble again, then the problem must be related to your environment Best Regards, Thorsten.

Hope that you don't feel frustrated from all my refusing answers, I only wanted to make my point clear - it's very hard to make a synth which is sufficient for everybody needs, therefore I've to priorize my own needs first (also in respect for the time I can spent for this project) I've read your wishlist for MBFM usage again and can only say, that all this is possible, but just sometimes requires one or two button movements to select the right display view for the soft-buttons/datawheel and the four GP encoders. How is the status of your FAQ? :) Best Regards, Thorsten.

Hi stefaN, at the beginning an important info: only the pcd5844 example app contains the driver, this means that you have to copy the app_lcd.inc file into other applications when you want to use them together with the display. The example application also sets the LCD type to 7, so a wrong configuraton cannot be the problem. How did you test the connections? Best Regards, Thorsten.

great to read that it is working now after so long time! :) Best Regards, Thorsten.

you can do this by using keyboard split zones. Each oscillator has it's own zone, by default they are spreaded over the whole keyboard range. By reducing the zones to dedicated ranges and transposing the notes to the desired octaves you are able to play the oscs individually (with different sounds) Best Regards, Thorsten.

under my desk you can see two gray boxes --- I've a lot of such containers for all my running projects to keep the working place clean :) Best Regards, Thorsten.

Hi, you could write: SEQ_BUTTON_GP1 movlw 0x00 rgoto SEQ_BUTTON_GP_Cont_Trk2 ;; ... SEQ_BUTTON_GP17 movlw 0x00 rgoto SEQ_BUTTON_GP_Cont_Trk2 ;; ... SEQ_BUTTON_GP_Cont_Trk1 ;; was the SEQ_BUTTON_GP_Cont before movwf MIOS_PARAMETER1 movlw 1 << 0 ; select first track movwf SEQ_SELECTED_TRKS, BANKED goto SEQ_GP_Button SEQ_BUTTON_GP_Cont_Trk2 ;; for GP17..31 movwf MIOS_PARAMETER1 movlw 1 << 1 ; select second track movwf SEQ_SELECTED_TRKS, BANKED goto SEQ_GP_Button SEQ_BUTTON_GP_Cont_Trk3 ;; for GP32..47 movwf MIOS_PARAMETER1 movlw 1 << 2 ; select third track movwf SEQ_SELECTED_TRKS, BANKED goto SEQ_GP_Button SEQ_BUTTON_GP_Cont_Trk4 ;; for GP48..63 movwf MIOS_PARAMETER1 movlw 1 << 3 ; select forth track movwf SEQ_SELECTED_TRKS, BANKED goto SEQ_GP_Button this requires SEQ_BUTTON_GPxx functions. I'm not sure if this is an elecant solution (for so many buttons it's better to decode the shift registers directly), but maybe you are able to find the best solution by yourself once you got the chance to get more into programming. the reason is that you are normaly able to select multiple tracks at once in order to make changes on these tracks with a single button push. This won't work with your plans anymore (therefore in my oppinion using only 16 buttons --- but 64 LEDs of course --- is the most ergonomic way). No, this isn't possible, since the cores are not running totally in-sync. Means: it cannot be ensured that if one core samples a logic-1 or logic-0, the other sees this logic state at the same clock cycle. And once this happens (and it will happen several times per second), it could be that one core handles an encoder event one mS later than the other But you can already edit four tracks at the same time with a single MIDIbox SEQ, just select the appr. tracks with the track buttons. I've an important suggestion to you: don't think about such "problems" before you've built a very basic MIDIbox SEQ in order to get some impressions about the current handling. If you think that it isn't sufficient for your needs, you can always extend the basic setup if required. And you are able to play with the code in order to get some programming experience. Best Regards, Thorsten.

Hi Lorin, wow, I didn't know about the SPI->UART converter, where can I find it on the maxim page? Maybe this is the easiest way (and it could be a generic solution for additional MIDI ports to MIOS). 1) possibly loads the CPU too much and affects the realtime capabilities. When sending a UART frame you've to disable interrupts so that stable timings are guaranteed. With 19200 baud and 10 bit (start bit/8 bit data/stop bit) this means that a single byte transfer takes 521 uS. The problem: if a MIDI byte is received at this time, it could happen that it get lost (MIDI bytes are transmitted with 31250 baud). The PIC has a double buffered USART, so maximum time is about 640 uS that you have to ensure that both bytes will be queued into the MIDI In FIFO before an overrun) 2) as mentioned above, this is possibly the best solution. 3) also possible, but it's maybe better to access the second PIC via IIC instead of MIDI for better timings. Or via SPI If 2) provides no FIFO, then you could implement this in 3) in order to increase the performance (the application can send a lot of data to the SpeakJet without waiting for an "unbusy" on the serial line). But 3) also means more programming effort and more support effort (if you want to publish your project) Best Regards, Thorsten.

Really good work, Smash! :) Best Regards, Thorsten.

it still won't really help, because you are not able to sweep the pulse frequency smoothly from ca. 50 Hz to 1220 Hz due to the quantisation caused by the update rate. here the memory limitations (RAM/Flash) will also take place. Please understand that the synth specs grew in an organic way and there are many many things which play a role. To completely know what I mean, you've possibly to develop an own synth on a microcontroller ;-) Btw.: did you know that there are only ca. 20k free for the application itself. These are ca. 10000 PIC instructions. If you are still searching for more mighty synths, then it's either better to wait for some years once I've switched to a more modern micro, or build your dream synth on a PC ;-) Only limitation are the OP ADSRs and modulator volume (resp. the modulation index), they will only change with the next note, but this is a OPL3 limitation. Everything else (especially the software engine parameters) react like on an analog synth. This means for example: when you modify an envelope rate/level, changes will take place immediately. Thats your problem, I won't change the control surface anymore ;-) Btw.: these are encoders, the handling is really fast and from my impression absolutely sufficient. Note also that there are 8 soft-buttons below the LCD and a datawheel. If you would like to have a different user interface, then you have to program it by yourself. Hint: there is no free memory anymore for a more complex handling. You possibly need a second PIC only for the control surface. Select volume, turn on encoder #1, select Instr, change the frequency with encoder #2, select LFO1, change the speed with encoder #3 --- it's not too hard to learn, the LCD gives you the right hints. I must say that I cannot follow your problems ;-) for modulator: harmonic level, for carrier: transpose Best Regards, Thorsten.

Hi Wise, "unsigned int period" is not the period in milliseconds, but the number of clocks (with mode as prescaler) to trigger USER_Tick. An calculation example can be found in the MIOS documentation (http://www.ucapps.de/mios_fun.html#MIOS_TIMER_Init) Best Regards, Thorsten.

Hi, remove the :80 and it will work Best Regards, Thorsten.

MIDIbox64 can also output MIDI notes when you turn a pot :) Best Regards, Thorsten.

Hi, you need one MBHP_CORE, one MBHP_DINX4, one MBHP_DOUTX4 Some LEDs and (this time also) buttons are multiplexed in order to save money, but this will be clear once I release the interconnection diagrams. However, you should already be able to check the modules with the common test applications (just trigger the DIN with a cable to ground, and test the DOUTs step by step with a single LED) Best Regards, Thorsten.

Hi, thats no simple change. Maybe it works without much effort by changing SEQ_SELECTED_TRKS depending on the row of button you've pressed before branching to SEQ_GP_Button, but I'm not sure if this will cause side effects. And I'm especially not able to test such a change... 4 x MBSEQ: it's possible to synchronize the sequencers via MIDI clock, and you could also control all parameters from external via CC, but it's not possible to control the "slaves" from one user interface (e.g. to display the values of other sequencer on the master displays) The first suggestion is madeble... but the problem is that I'm not able to test such changes with my own hardware. Therefore it has to be done by yourself. Best Regards, Thorsten.

Hi, I've tried a lot of things :) Mostly I'm using Reaktor for realtime Fx processing, the results are far away from that you know of common Fx gear - the possibilities of this modular environment are incredible. this was also in my intention :) Sure, you can put as much bytes as you want into a SysEx dump, but you also have to consider that the available infrastructure must be adapted as well. Means: the JSynthLib editor, TL's patch manager, Serge's SysEx loader, the slave SIDs, etc... a patch converter would have to be written in order to recalculate the checksum... the documentation would have to be overworked, the support effort would be higher due to frequent requests in the troubleshooting section ("why I'm not able to load this patch into my MIDIbox SID anymore...", "why can i only store 64 patches in the BankStick anymore...") and not at least it requires a lot of (small) changes on different places in the firmware. What you are requesting would lead to a lot of tasks for different people, this process could take months until everything is aligned again. Btw.: thats also the reason why MIDIbox FM is not available for public use yet. I must be very sure that I have considered everything which is possible with the small PIC before I release a version with which other people are working, because each change after an initial release which makes it incompatible will cost three times (or more) the effort. Remember: the waveform will be updated each 819 uS. If the LFO would generate a sawwave with ca. 1220 Hz, the output value would always be the same. If the saw would be set to 610 Hz, you would only see two different values, etc... thats not a saw anymore However, if you need trashy waveforms, then just use the wavetable sequencer ;-) Best Regards, Thorsten.

Super! :) Gruss, Thorsten.

Hi D, no, this is also a future feature (which won't be developed by myself, but by another forum member --- but he should introduce this project by himself once he feel ready for this :-)) - it will require an expensive (already assembled) FPGA board, so it's only for real freaks yes, the analog power out is for the AOUT module, the digital power out is free for anything else (I like to have those additional connectors). The digital domain of the AOUT module is powered from the 6-pin DIN connector. 5 pins are going directly to the AOUT, 4 of them are shared together with the 6th pin for a "DOUTX1" module which provides 8 gate outputs. Best Regards, Thorsten.

Thats the connector for my AOUT module (8 CV outputs) - my MIDIbox SEQ has the same. CV outputs are planned as future extension Best Regards, Thorsten.

Some closer views: Best Regards, Thorsten. P.S.: the DINX4 and DOUTX4 module are donations from Rasmus the CORE module is a donation from SmashTV the OPL3 module is a donation from d2k the panasonic rotary encoders are also a donation from d2k the 2x40 LCD is a donation from Hallucinogen the front- and rearpanel have been payed from MIOS donations :)

Hi, MIDIbox FM is up and running (see this picture, MBFM can be found above MBSEQ) I'm waiting for the final layout so that the PCB can be released. Best Regards, Thorsten.

It's great, I like it! :) Best Regards, Thorsten.

This is the same view of today (note the new instrument above MIDIbox SEQ :-)) Best Regards, Thorsten.