TK.

Wenn die Multi-BankStick option erstmal in der MBSEQ V3 implementiert ist, wird die Groesse in main.asm einstellbar sein. Ein 32k BankStick kann dann 64 Patterns speichern, ein 64k BankStick 128 Patterns. Fuer den Songmode benoetigt man noch einen zusaetzlichen 32k BankStick, oder man kombiniert Song/64 Patterns auf einem 64k BankStick, so wie bei der MBSEQ V2 Gruss, Thorsten.

Hallo, zum Soundblaster kann ich nicht viel sagen, aber "Unknown Device" koennte darauf hinweisen, dass der Treiber Deines MIDI Treibers keine Multi-Client Option unterstuetzt. Es kann also immer nur ein MIDI Interface auf den MIDI-Port zugreifen, alle anderen erhalten eine kryptische Fehlermeldung. Abhilfe schafft ein virtueller MIDI Port wie bspw. MIDI-Yoke - siehe auch http://www.ucapps.de/jsynthlib.html Gruss, Thorsten.

The stack boundaries are defined in the file header of mios_wrapper/mios_wrapper.asm: ; the upper boundary of the stacks are defined here ; customize the values for your needs #ifndef STACK_HEAD #define STACK_HEAD 0x37f #endif #ifndef STACK_IRQ_HEAD #define STACK_IRQ_HEAD 0x33f #endif [/code] The default setup is 64 bytes for main tasks, 64 bytes for interrupt tasks. (stack pointer is counted down, there is no collision control to save runtime) Since a PIC18F4620 has enough memory, you could use two 256 bytes stacks located at the upper RAM pages: #define STACK_HEAD 0xeff #define STACK_IRQ_HEAD 0xdff this should relax the situation. Note that the appr. memory area (0xd00-0xeff) should be reserved in the projekt.lkr file Best Regards, Thorsten.

Please note, that the correct writing is "MIDIbox", not "MIdibox" Best Regards, Thorsten.

It isn't a big problem to ensure that incoming MIDI data won't get lost, when you are writing an own handler which checks for new data periodically. The period must be less than 320 uS -> see also the MBHP_TV application Best Regards, Thorsten.

Just think about it: do you think that I would ever throw away my existing MIDIbox SEQ frontpanel? Apparently, it's an optional feature, and I for myself will built this into a seperate 19" rack case. The sequencer works nice without the Button/Duo-LED matrix - it's just one of many features :) The schematic is a mix of the button and historic single-colour LED matrix, I will publish it once I find the time to draw the connections. Here some additional infos from the ChangeLog: [tt] o overworked LED matrix, implemented button matrix There are several configurations possible, here the tested ones: a) historic 4x16 LED matrix which replaces the 1x16 GP LED row Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 3 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 4 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; can be optionally selected if LEDs with high power consumption are used #define DEFAULT_SRM_DOUT_DUOCOLOUR 0 ; no DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 0 ; no button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_L 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_R 0 ; only relevant for button matrix Note: compared to the old schematic, the cathodes are now mirrored! This means that you have to change the wiring on your existing hardware Upper Row: DOUT pin D7 second Row: DOUT pin D6 third Row: DOUT pin D5 fourth Row: DOUT pin D4 b) 16 "GP LEDs" + 4x16 seperate LED matrix recommented solution, since this allows the firmware to display menu parameters seperately below the LCDs Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 6 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 9 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; can be optionally selected if LEDs with high power consumption are used #define DEFAULT_SRM_DOUT_DUOCOLOUR 0 ; no DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 0 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 0 ; no button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_L 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_R 0 ; only relevant for button matrix c) 16 "GP LEDs" + 4x16 seperate DUO LED matrix recommented solution, since this allows the firmware to display menu parameters seperately below the LCDs Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 6 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 9 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; SHOULD be selected with DUO LEDs (high power consumption) #define DEFAULT_SRM_DOUT_DUOCOLOUR 1 ; DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 7 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 10 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 0 ; no button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_L 0 ; only relevant for button matrix #define DEFAULT_SRM_DIN_R 0 ; only relevant for button matrix d) 16 "GP LEDs" + 4x16 seperate DUO LED matrix + 4x16 seperate button matrix recommented solution, since this allows the firmware to display menu parameters seperately below the LCDs The 4x16 additional buttons should only control the step gates (and other assigned triggers) Required settings in main.asm (or alternatively setup_*.asm) - search for the values and change the numbers: #define DEFAULT_SRM_ENABLED 1 ; enable the LED matrix #define DEFAULT_SRM_DOUT_L1 6 ; DOUT register of the left side (8 LEDs) #define DEFAULT_SRM_DOUT_R1 9 ; DOUT register of the right side (8 LEDs) #define DEFAULT_SRM_DOUT_CATHODES1 5 ; DOUT register which controls the LED cathodes - 4 pins used #define DEFAULT_SRM_DOUT_CATHODES1 6 ; SHOULD be selected with DUO LEDs (high power consumption) #define DEFAULT_SRM_DOUT_DUOCOLOUR 1 ; DUO colour LEDs #define DEFAULT_SRM_DOUT_L2 7 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_DOUT_R2 10 ; only relevant for DUO colour LEDs #define DEFAULT_SRM_BUTTONS_ENABLED 1 ; using button matrix #define DEFAULT_SRM_BUTTONS_NO_UI 1 ; only control gates (and other assigned triggers) with these buttons #define DEFAULT_SRM_DIN_L 11 ; DIN register of the left side #define DEFAULT_SRM_DIN_R 12 ; DIN register of the right side o there are now 4 additional buttons and LEDs for selecting the track group (G1=track 1-4, G2=track 5-8, G3=track 9-12, G4=track 13-16) The pin assignments are made in mios_tables.inc (or within the setup_*.asm file) [/tt] Best Regards, Thorsten. P.S.: thanks for your nice feedback! :)

I've added the question to the FAQ. Bosone: please let me know once you have your PIC18F4620 based MBSEQ up&running (via email), so that I can send you the latest snapshot with improved live record function But as Steve said: this is a different topic and should not discussed in this thread Best Regards, Thorsten.

Die Anzahl der eingesteckten EEPROMs spielt keine Rolle, zur Platzierung kann ich nichts sagen, man erkennt es eigentlich an der Codierung zwischen Pin1, 2 und 3 (+5V = 1, 0V = 0) Vielleicht koenntest Du sie ja mal herausfieseln, und ins Wiki stellen? (Eine Skizze waere nett, ich kann sie dann auf den midibox.org Server aufladen) Falls Du aus der Schaltung nicht schlau wirst, stecke das Board einfach mal an die MBSID, und ueberpruefe, welche Baenke formatiert werden. Gruss, Thorsten.

Great! :) Best Regards, Thorsten.

For the case you missed this: Best Regards, Thorsten.

Where are you living? Maybe there is somebody who lives close to your location and could help you (or you could send him the PCB via mail service) - all your assumptions cannot be answered remotely without testing the circuit, because when you are very sure that the boards are soldered correctly, and if you are sure that you connected the LED at MIDI Out with the right polarity, it must flicker. Otherwise the only possible reason I know is, that the bootloader hasn't been burned into the PIC, but this is unlikely, since this never happened before Best Regards, Thorsten.

(I've merged the two articles in order to avoid, that people miss the new findings) Best Regards, Thorsten.

It could also be that your PSU works out-of-spec, means: the output voltage already sinks even when the circuit draws less than 500 mA. A better PSU helps to reduce the hum significantly Best Regards, Thorsten.

The previous code of lc_init.inc is now located in main.asm, USER_Init function. It's not referenced in the program, but yes: there are two comments which refer to lc_init.inc instead of USER_Init Best Regards, Thorsten.

have you already seen the code? Does it look familar to you? I've a test application for my 4x16 Button/Duo-LED matrix, but it can only adapted to 3-colour LEDs by skilled assembly programmers, and it cannot be integrated into the MBLC application. However, this doesn't make much sense anyhow, you want to develop a different protocol, therefore it will be possibly easier for you to build up the application from scratch. For general RGB LED handling: see also this article: http://www.midibox.org/forum/index.php?topic=5626.0 Best Regards, Thorsten.

Schau mal bei pollin.de vorbei, die verramschen passende Netzteile fuer <5 EUR Gruss, Thorsten.

Sidenote: I'm not 100% sure, since I never tried this, but it's maybe worth for an experiment The Timer() function will be triggered on a Timer3 overrun. This Timer can also be clocked from external (RC0 pin). According to the datasheet, you only need to set the TMR3CS flag of T3CON From the software side this means: - disable interrupts (INTCONbits.GIE = 0;) - initialize the timer so that it is executed with each clock (MIOS_TIMER_Init(0, 0)) - enable external clock (T3CONbits.TMR3CS = 1;) - enable interrupts again (INTCONbits.GIE = 1;) now Timer() should be called on each rising edge on pin RC0 Just want to mention it again: I never tried this out! So, it could be, that some additional configuration is required, or that MIOS overwrites something which prevents you from using the external clock pin - I only remember, that MIOS_TIMER_Init overwrites T3CON completely, therefore I proposed to change the TMR3CS function after this call, and to temporary disable interrupts in order to prevent that the Timer() function will be called endless so long it is clocked from internal (in this case your core will completely hang up, and a watchdog reset should happen after some seconds) Best Regards, Thorsten.

Great link, I especially like the examples about the self oscillation :) Best Regards, Thorsten.

An update of all LEDs/LED rings, etc... is so fast, that you won't regognize it. Motorfaders need a little bit longer, but this is not a problem with the protocol, but more a mechanical issue ;-) Here a link to the logic control manual which contains a detailed description about the MIDI implementation: http://www.netzmarkt.de/thomann/prodbilder/151261_manual.pdf Best Regards, Thorsten.

1A should be prefered, 5A could damage the transformer or the rest of the circuit on shorts Best Regards, Thorsten.

On the other hand: when the LED does not flicker on test TEST OUT1, it's very likely that the PIC is not running - just double and tribblecheck the schematic vs your board (missing components, bad or missing solders, PIC plugged the wrong direction into the socket) Best Regards, Thorsten.

Win98: here TEST_PC1 and TEST_PC2 is extremenly important, user reported a lot of driver problems with this old windows version Best Regards, Thorsten.

great! :) Best Regards, Thorsten.

In the last time it happens very often, that people ask questions like "does MIDIbox XX support feature A like my favourite device B". This is what I find a little bit frustrating, because it definitely sounds like a demand, and leads the dialogue into a wrong direction. So, let's talk about these topics on a different basis. I especially find it very important, that you now have descibed your ideas in more detail, this makes it much easier for myself to think about an adequate solution, instead of forcing me to work out a concept which could match with your wishes. there is no special list, I just send the snapshots to people who asked me for beta testing. It is not so easy to provide two additional parameters (min/max limit) for such a minor feature. The reason is the way how I've organized the memory. Currently each track allocates 32 bytes for parameters, in the meantime only one spare byte is available anymore, and this is reserved for really important things, which could be added in future. I don't want to reserve a larger area for track configuration data, since this wouldn't allow me anymore to store 128 patterns in a 64k BankStick (as programmer you propably know, how important the 2^x values are) However, your idea can be realized on a different, and in my eyes on a much more flexible way. There is a CC for semitones, and another CC for octave transpose. Thanks to the internal loopback port it's possible to play these CCs from one track, and to send them to another track. This means in other words, you can control the octave or semitone transpose from a second track. By setting the clock divider of this track to a high value, it's possible to change the transpose value after each 16 steps of the "note track". One track can send up to 3 CCs In addition, there are things possible, about you've propably not thought about yet. :) E.g., the control track can be forwarded with a special progression pattern (what you see in the last video), or randomly, or manually, or ... In general I don't support pitch bend anymore, since the MBSEQ works internally with 7bit values, so using Pitch Bend results into the same like using a CC mapped to a detune (finetune) parameter of the synth. The concept is flexible enough, that I could add a new event mode which sends Pitch Bender events, but I don't see much use for it. But this is only some background information, and not the answer to your question. Do I see it right, that you mean a semitone transpose - than it would work in the same way like for 2) --- yes, it's possible to control a "CC length", which means: CC will be set to the step value for a given gate time, and thereafter set back to 0 Currently this has to be done by setting the gate length to maximum, so that the step will be tied with the next step. By doing so, a note can be held over the whole track length. But it wouldn't be so difficult to add a "sustain flag" - I will do this problem here is, that the sequencer has to memorize the played notes if they should be killed on command. This consumes a lot of memory - since there are 5 MIDI Out ports, and 16 MIDI channels, 10240 notes = 1280 bytes would be required (so much RAM is not free anymore). A "All Note Off" CC could do the same, but most of the synths I own don't support this... Alternatively Note Off events could be sent over all channels and ports, but this consumes a lot of time (for 10240 notes: 10 seconds) (this is possible) unterstood. Problem here is, that I don't know, where to store the pause within the layers. Only possible position would be the gate delay, but it's already 5 bit (due to the 96ppqn resolution), and the remaining 2 bit are used for the double/tribble/quadruble step triggering. What I could do is to add a mode, which turns the double/tribble/quadruble step triggering into a 2x, 3x, 4x pause, but I don't know if this is really flexible enough. And it would mean that I have to do a lot of changes at different places within the firmware, since such a change hasn't been considered at the beginning. It depends, for delay you can only set static values or the "groove intensivity" parameter, which can be changed via CC (think about the loopback possibility). Negative delays are not possible. For Velocity and Length you can set percentages (20%..160% in 10% steps) or the groove intesivity parameter (again) Best Regards, Thorsten.

Hi, MIOS doesn't run on PICs with integrated USB peripheral, this means that you would have to implement the operating system from scratch. In addition, you propably have to write your own windows driver if you want to transmit events which don't comply to the MIDI protocol. However, by using NRPNs or Pitch Bender events, it is already possible to send 14bit values, so one of the fist steps would be to read the MIDI spec (see also ucapps FAQ) What do you understand under "fast"? How many values need to be updated within which time? there is not that much documentation available, only the schematics at ucapps.de there are different ways, they should be documented in the manual which comes with Cubase (I'm not a Cubase user, therefore I cannot help here - for Logic a special LC manual is available, the link is in the Wiki) they use multiple MIDI IO ports (so, it's not chained) the maximum resolution provided by the LC protocol is 14bit (faders send and receive pitch bend events), but the PIC only provides a 10bit ADC Best Regards, Thorsten.