TK.

Ok, then the MIDI channel and oscillator assignments are working. Since SID-R is working with other engines, I guess that it's related to the filter or waveform settings. Best Regards, Thorsten.

Thanks for the feedback! I find it better as well, on the other hand I don't like the flaw in combination with the SELECT button. However, if nobody really minds about this issue, then it's ok for me ;) Remote Control: the code is located in seq_sysex.c: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v4%2Fcore%2Fseq_midi_sysex.c keyword "remote" Since the hooks are there, it wouldn't be so difficult to provide a similar solution for Note/CC based communication. Update: I just noticed that Button and Encoder events are already sent as Notes and CCs - just only the LED state is SysEx (for best performance). A one-to-one LED control is too slow over a common MIDI line. It could work over a USB MIDI based line assumed that a novation launchpad can handle USB as fast as MIOS32. Best Regards, Thorsten.

Such a function is already available, but not documented: a master/slave remote control! :smile: In Remote Master mode it sends LCD and LED updates to a MIDI port, and receives MIDI events for button and encoder movements. The same in Remote Slave mode, just vice versa. The protocol is based on SysEx. I implemented this in order to allow a fully stuffed MBSEQ V4 to connect and remote-control another "core-only" device without control surface. It would also be possible to connect to a computer app which provides the protocol. Later (iPad came to the market) also the usage of a table PC came into my mind. (While I'm writing this: I remember that somebody started with a Lemur based app, but can't find the posting!) Idea was, that a newbie could explore the possibilities of MBSEQ by only building the core before he builds the control surface. Another idea was, that somebody could implement an app which acts as some kind of "frontpanel design", so that somebody can design his own "personalized control surface". However, these were only wild ideas, at the end I came to the conclusion that the benefit/effort ratio is not so high, resp. that I would need help from somebody who takes over the implementation of the app part. And maybe another guy who writes the documentation (because this is a lot of effort as well...) The BLM protocol is already based on MIDI. Actually the BLM16x16+X is a remote device - and even a virtualized version is available, see: http://www.ucapps.de/midibox_seq_manual_blm.html I need some feedback on the current implementation: Currently the step recording can be temporary enabled by pressing a GP button, and it can be permanently enabled by the SELECT button. Problem: if somebody turns on recording via SELECT button, the mode will be disabled once he presses a GP button (e.g. to select, activate, deactivate a step). Therefore I think it's better to remove the initial "activation via GP button" function. And thinking a step further: recording could also be enabled by pressing EDIT + a GP button (e.g. GP6 and GP7 are unusued yet) This would free up SELECT for other things. Opinions? Best Regards, Thorsten.

Very nice! (I like kraftwerk and your style) Best Regards, Thorsten.

Still strange... but the LED meters for O4..O6 (above the sammichSID display) are triggered whenever you play a note on MIDI channel 4..6? Best Regards, Thorsten.

Bug came in with v4.084, fixed in v4.086_pre3 Best Regards, Thorsten.

Yes, a new video will be necessary, because this (actually obvious) feature changes the way how to enter&edit sequences entirely, at least for those users who are working with an external keyboard. The usage is now very similar to MBSEQ V4L :smile: Alright, here a new version: http://www.ucapps.de/mios32/midibox_seq_v4_086_pre3.zip still work & progress, but I considered some of your proposals and I'm interested on more ideas to improve the recording mode. Changes: improved CC recording ALL button considered now press&hold EDIT button to select the view mode, select random or euclid editor, etc (that what was previously done with the SELECT button) the SELECT button gives you now an alternative possibility to enable recording, e.g. for the case that you want to enter a chord with two hands on your MIDI keyboard. Note that by pressing & depressing a GP button recording mode will be deactivated again. Just use the datawheel to select the step into which you want to record something avoid MIDI note hangs if recording function is used for a chord layer CLEAR button now clears all selected tracks Comments to your other proposals: haven't considered this yesterday evening, should work now conflicts with the ALL button behaviour where you want to get an oversight about the steps into which the MIDI events are recorded. It's a different topic, which needs more alignment with different users to find out how they would use it. E.g. I wouldn't like to enforce the usage of a certain MIDI device like a Korg Nanocontrol, it would be better if such a remote control option would also consider other devices. I added your proposals to the Wishlist and will come back to this in a separate forum topic sooner or later once the current MIDI learn topic is finished. I totally agree with this, and therefore changed the selection. (originally I wanted to use the SELECT button to enable the record function - it's implemented this way now) The reason was, that only a single track can be stored into the UNDO buffer. However, I guess that most people don't use the UNDO function anyhow, or would accept this limitation. Therefore I enable multi-track clear Best Regards, Thorsten.

Here another version which supports step recording in the EDIT page! :-) -> http://www.ucapps.de/mios32/midibox_seq_v4_086_pre2.zip Press&hold a GP button and play some notes or CC from an external MIDI keyboard into the step. Best experience with tracks which are configured for at least 8 parameter layers, and which have some layers assigned to Notes (to enter chords) and some other layers for CCs The CC number will be auto-learnt. The MIDI Record port and channel has to be configured in the UTIL->Record page I had a lot of fun with this new function today and I'm interested on your feedback for improvements. Best Regards, Thorsten.

There might be some confusion about the SID item. Actually it selects the sound engine (= PIC Core connected over the MBNET network) Each SID (= PIC core) controls two SID chips, the left and the right SID. Another reason why it could behave this way: you've to assign dedicated MIDI channels or keyboard split zones in the INS menu, see also: http://www.ucapps.de/midibox_sid_manual_e.html Best Regards, Thorsten.

Great! :smile: yes and no ;-) num_sr defines how many bytes have to be bidirectionally transferred over the SPI interface and processed by MIOS32. The number depends on the DIN and DOUT shift register chain length. The longest chain defines the amount of bytes which need to be transfered. So: if the DIN chain is longer than the DOUT chain, you set the number of DIN shift registers. if the DOUT chain is longer than the DIN chain, you set the number of DOUT shift registers. if the DIN and DOUT contains an equal number of shift registers... ok, I think that you get the point now ;) Best Regards, Thorsten.

Check the VAs (Voice Assignments) configuration in the CFG menu. Details are here: http://www.ucapps.de/midibox_sid_manual_m.html For 6 mono voices it makes sense to statically assign them to dedicated oscillators (O1..O6) O1..O3 are the oscillators of the left SID chip, and O4..O6 the oscillators of the right SID chip. If you still don't get any sound out of the right SID chip, check the filter configuration. It could be that you've enabled the filter for certain channels, and that the cutoff frequency is 0 Best Regards, Thorsten.

Yes, you could invert the pins with an ULN Best Regards, Thorsten.

It's the board that we discussed here: -> currently not supported, and will lead to incompatibilities -> sell it Best Regards, Thorsten.

Hi, here some first statements from my side w/o checking if an implementation is really feasible for V4, or could only be part of V4 Plus since it requires a patch structure update. do you want to enter the CC number, or just select the parameter layers which should be humanized? The parameter storage is limited to 1024 bytes, and the trigger storage to 256 bytes. For a parameter storage each step consumes 1 byte per layer, in the trigger storage 8 steps consume 1 byte per layer This "full blown" parameter option 16 parameter layers and 8 trigger layers is already available, but you've only 64 steps (64*16 = 1024 bytes, 64*8/8 = 64 bytes) A drum track would multiply the required storage depending on the number of instruments. E.g. with 16 instruments such a configuration would consume 16k for only 64 steps. This is dramatically more memory, and even worse: it takes much more time to load (and store) this amount of memory from/to SD Card. Realtime switching between the patterns wouldn't be possible anymore. Is this what you would accept? (I don't think so) So: I understand your request, but I don't see a potential for improvements here if we want to keep the major advantages of MBSEQ V4 (regardless if with or without Plus) I also already spent some thought on this, e.g. to allow multiple length (and also velocities) in a track. It's possible to provide this. But we've 16 parameter layers maximum and have to keep this limit. So: how many parameter layers are you normally using, and would it be acceptable to spend some layers for additional lengths? Would it be sufficient to allow the possibility to set the existing loop point only for certain parameter layers, and not all parameter layers? How should the triggers be handled in this case? Would it be sufficient to provide a SW based configuration of the already available chord function? And are you requesting dedicated chord entries for each track, or a pattern based chord entry, or a session wise chord entry? Should be possible as a configuration option. ok how do you want to configure this, what kind of variety do you need (resp. how would you configure it) - take it as a use case) As a replacement for a length layer, or just a different entry mode for the existing length layer? do you mean note selection or layer selection? How should it look like in the GUI (the euclid page is already very crowded) what should happen when you select multiple groups? Already possible with the copy&paste function. Press copy, then press&hold paste and move an encoder to shift the paste buffer to the end of the track I know... tracked in the wishlist /Update: implemented in v4.086 Delay note is already possible, it's the "delay" parameter layer, or do you mean a different kind of delay? Repeat, length and divider can't be defined in a step because these parameters have to be available *while* the sequencer decides the next step. ok /Update: implemented in v4.086 LFOs are "expensive", because we've 9 parameters which need to be stored in the 128-byte CC range. Means: if I add a second LFO, I've to reject 9 potential "nice features" in future. So: how important is this feature? I would only change this if multiple people request this - I wouldn't use it by myself, because I prefer LFO modulation at the synth side, and only use the SEQ based LFO for Notes. Ok. Btw.: I'm planning to improve recording anyhow, so that it's possible to record from the EDIT page by selecting the step which should be recorded Memory<->Performance issue, see 2) I will add this to the wishlist, but making all parameters accessible will result into a lot of effort at my side :-/ Because I guess that you also want to get a (temporary) display of the changed value while you are moving the encoder, right? ok. Btw.: such a function would allocate memory of the CC memory space (128 bytes) Is this function more important than a second LFO? Ok. But note again that in future we will have a more comfortable recording anyhow (from the EDIT page). It could be that you won't use such an option anymore... So: how important is this request, is it essential that you would even use it if an alternative (improved) way for step recording is available? Sending all data via a common MIDI port will consume a lot of time and stall the sequencer due to the limited MIDI bandwidth. E.g. sending out all CCs of all 16 tracks takes ca. 2.5 seconds - and in this case I even haven't considered that some CCs are 8bit (instead of 7bit) meanwhile - a "hack" that I unfortunately had to do in order to make other requests possible. Such parameters would have to be sent via 14bit NRPNs, which increases the time to ca. 5 seconds. Really useful? It's again a lot of work for a feature which I wouldn't use by myself. Therefore my question: are there other users interested on such a function? Best Regards, Thorsten.

E.g. let's say somebody wants to construct an unusual NRPN value format for a certain synth, the nested operations will help you to do this. Or somebody needs an IF condition depending on a certain bit of a value such as [^value & 0x40] == 0x40 -> now possible. Of course, I will give more examples in the documentation sooner or later, but I guess that most users need a direct specification from my side to solve a configuration issue. My advantage: I don't need to enhance the firmware anymore for such special cases. SRIO: Serial Register Input/Output -> MBHP_DIN, MBHP_DOUT, MBHP_DRIO You don't need new hardware to test this... Some time ago you complained that the scan latency of a keyboard is worse when using MBNG compared to MBKB. By reducing the number of scanned shift registers you will get the same performance. Best Regards, Thorsten.

Hallo, die PitchBend Events werden gesendet, weil die analogen Eingaenge an J2 noch nicht angeschlossen wurden. Alle ungenutzten Eingaenge (A0..A7) muessen auf Masse (=Vs) geklemmt werden. Nun moechtest Du jedoch den ersten Eingang A0 nutzen, also nur A1..A7 auf Masse. Fader Pinbelegung: J2:Vs auf Pin 1 J2:A0 auf Pin 2 J2:Vd auf Pin 3 J14:T0 auf Pin T Gruss, Thorsten.

I've improved the math calculation handling a bit. It's not relevant for that what you are doing, but could be helpful for others in future. Update to v1.032_pre2: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre2.zip Now you can add spaces between operands and operator, such as: [LED:2000 / 128] to make the code more readable. And even nested operations are possible, such as: [LED:2000 + [LED:2001 + [LED:2002 + LED:2003]]] Something that could be even more interesting for you is the new "SRIO num_sr=<1..32>" parameter. It allows to reduce the number of scanned shift registers. E.g. let's say you've connected 4 DIN SRs and 2 DOUT SRs. The longest chain are the 4 DIN SRs Accordingly you can set: SRIO num_sr=4 Now your keyboard will be scanned 8 times faster than before! :smile: Best Regards, Thorsten.

I just have added a new parameter to the .NGC file. Just upload this prebuilt binary: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre2.zip Now you can reduce the number of scanned SRs with (for example): SRIO num_sr=4 in your .NGC file Best Regards, Thorsten.

Hi Mathis, yes, your assumptions are correct. I just noticed that the number of scanned SRIOs isn't configurable. By default, the MBNG firmware will scan 32 DIN and 32 DOUT shift registers with each update cycle, but I guess that you don't use more than 4 DIN shift registers, which means that if the number would be configurable, so that only 4 SRs are scanned, you would be able to scan the keyboards with an update rate of ca. 0.5 mS You could already try this out by changing the MIOS32_SRIO_NUM_SR value in src/mios32_config.h Best Regards, Thorsten.

First you have to change the value limitation to allow a value entry in the range of 0..255. In the different sections you will find "if" conditions which check for certain numbers, e.g. in section 1..7 it's checked that the value is <= 12 Why? because we want to ensure that it isn't possible to enter a value > 127. A program change ranges from 0..127, values above this range are invalid. Example: If somebody would enter '1', and then a '3' (-> 13), an additional '1' would result into 131 -> invalid value! Therefore only <= 12 is allowed. Now you've to change it in a way that value between 0..255 can be entered, and all other values are blocked. To give you some hints: for ^section 1 it will be <= 25 ;-) Once you are able to enter values between 0..255, replace the MIDI event sending code by: # EXEC button if ^section == 11 # valid number? if LED:2001 == 1 if LED:2000 < 128 # Bank 1 send CC USB1 1 32 0 # Program Change send ProgramChange USB1 1 LED:2000 else # Bank 2 send CC USB1 1 32 1 # Program Change # modulo operation: ensure that PC value is in range between 0..127 send ProgramChange USB1 1 [LED:2000 % 128] endif # next entry will reset the number set LED:2001 2 endif exit endif This could also be simplified with: # EXEC button if ^section == 11 # valid number? if LED:2001 == 1 # Bank = value / 128 send CC USB1 1 32 [LED:2000 / 128] # Program Change # modulo operation: ensure that PC value is in range between 0..127 send ProgramChange USB1 1 [LED:2000 % 128] # next entry will reset the number set LED:2001 2 endif exit endif This code is untested - in case of errors, please first try to debug this by yourself! Best Regards, Thorsten.

Yes, it makes sense to do experiments with the given possibilities. Well, it's limited because in a "Note" MIDI message we can only differ between 128 different notes per channel. Has your keyboard really 256 keys? Or is this because of the unusual matrix mapping... or are we speaking about multiple keyboards? Btw.: since it doesn't provide velocity anyhow, you could alternatively handle it like a common DIN_MATRIX, which gives you a bit more flexibility. E.g. it allows to define individual EVENT_BUTTON for each key, so that you can define dedicated note numbers and MIDI channels. Best Regards, Thorsten.

Yes, you can now add similar commands for any other value, just store them into different LED:xxx numbers (the LED event actually acts as some kind of memory, resp. variables). Then you could also use another LED:yyy to switch the keyboard between the different selection modes. It will result into a lot of "spaghetti code" (.NGR is no elegant programming language, but just a dumb command interpreter), but you will be able to implement this with the given functions. Best Regards, Thorsten.

Hi Mathis, there won't be a generic solution for such a special scrambling, but I could add a simple note mapping function similar to the velocity mapping into the firmware as demonstrated here: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fkb_2.ngc Would this solve the problem? Then I could enhance the firmware by this function quickly. Best Regards, Thorsten.

Hi, you could use a MBHP_CORE_STM32F4 + MBHP_MIDI_IO module + a USB Micro-B -> USB 2.0-A adapter See also Best Regards, Thorsten.

This is probably the most tricky script that I ever wrote so far ;-) Try this version: http://www.ucapps.de/mios32/midibox_ng_v1_032_pre1.zip It supports math operations in a .NGR script! :shifty: Configuration example: .NGC: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frunscr5.ngc .NGR: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frunscr5.ngr .NGL: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Frunscr5.ngl You can either use buttons connected to DIN shift registers, or you could use a real keypad connected to DIN/DOUT in a suitable DIN_MATRIX configuration (not shown in this example, but it shouldn't be so difficult to configure this...) Best Regards, Thorsten.