TK.

Hi, this was a temporary glitch which is fixed meanwhile. E.g. in this pre-release: Best Regards, Thorsten.

Yes, can be created very easily with a parameter layer assigned to Roll2, no need to use another track. Search for "Roll2" here: http://www.ucapps.de/midibox_seq_manual_m.html There is an open request in the wishlist which would allow similar effects: ---------------------------------------------------------- Trigger steps from another track: ---------------------------------------------------------- but it isn't implemented yet Best Regards, Thorsten.

I implemented the "Nth" mode today - have fun! -> http://www.ucapps.de/mios32/midibox_seq_v4_088_pre17.zip o added new parameter layer "Nth" which triggers a special action on each nth bar. Following trigger conditions are available: - Pl (Play each nth bar) - Mu (Mute each nth bar) - Ac (Accent each nth bar) - Ro (Roll each nth bar) - Fx (enable Fx each nth bar) - Nx (don't enable Fx each nth bar) Unfortunately "Skip", explicit "Random" and explicit "Echo" isn't possible with the way how the core engine is implemented, therefore I renamed these modes to "Fx" and "No Fx" This is a release candidate for V4.088 Major update is in the Record and Live screen. The new live patterns won't be stored yet - I will add this soon and then officially release V4.088 New features won't be added to V4.088 anymore (I would like to get this stable after considering so many requests...) Should work as requested with v4_088_pre17 Best Regards, Thorsten.

I don't implement each "quick idea", only if there are very good reasons (and/or multiple people find it useful). However, the new subsubpage has been added: http://www.ucapps.de/mios32/midibox_seq_v4_088_pre15.zip Best Regards, Thorsten.

Especially if this feature (which should be commonly supported by all MIDI devices) is explicitly mentioned in the user manual it could be related to a problem in earlier firmware versions... ;-) Best Regards, Thorsten.

Alternatively: would it be acceptable to switch only between 14 patterns, and to use the 1st GP button to turn on/off the feature, and the 16th GP button to switch back to the original page view? Best Regards, Thorsten.

Thanks for the feedback! :) Since the same change is available in MIOS32, I guess that your station project will also benefit from this :-) -> Best Regards, Thorsten.

Hm... it's too long ago where I worked on this code (9 years ago!) Could you please check if the NRPN based value change will be displayed on the LCD in the corresponding page? Then I've a simple explanation: the value will be written into the edit buffer, but won't be transferred into the shadow buffer which is used by the sound engine Accordingly, it would be required to copy the value into the edit and shadow buffer (and not only in one of these buffers). Best Regards, Thorsten.

Hi, no further information required - it's a known limitation of the .NGR approach, and there is no workaround. However, you are now the second guy who describes a use case which requires an improvement. See also: So, more likely I will work on a solution - anytime soon ;) Best Regards, Thorsten.

An interesting hack! ;-) But it won't work for receiving the values, and this would be a function which would require some firmware extensions (and consume some memory to make it generic) Best Regards, Thorsten.

Well, by changing SID_PATCH_BUFFER_SHADOW to SID_PATCH_BUFFER (at many places in sid_parin.inc and sid_parout.inc) values would be written (and read from) edit buffer instead of the shadow buffer, but this will also result into destructive write operations from the WT sequencer and some other functions. Best Regards, Thorsten.

Hi, how do you process the events? Are you calling a .NGR script section? Best Regards, Thorsten.

Hi, it isn't impossible, but difficult to implement. Looking at my backlog for various projects, it could take several months until I will find the time to implement such a challenging feature. So: better don't wait for this and search for alternative solutions. Best Regards, Thorsten.

Hi, I hope that a sammichSID user who successfully tried an OLED will answer. Best Regards, Thorsten.

Glad that it's working :smile: I don't like the special pattern selection page, although it would be a nice-to-have function. It leads to a deep menu hierarchy, but the MBSEQ user interface wasn't made for this. E.g. there is no standard way to come out of such a page (all GP buttons are allocated... so it couldn't be a soft function). And everything which isn't standard, means that I've to overwork some parts of the firmware. So: I would only add this if there are strong reasons (or if I would use such a function by myself ;-) However, you probably haven't noticed yet that pattern editing is already possible: just press the SELECT key in this subpage. Best Regards, Thorsten.

Nice idea & easy to implement - I added it to the wish list :smile: I would say that a modulo over up to 16 bars should be enough. Since a step value contains 7bit, it means that 4 bits are used to set the modulo, and 3 bits could be used to encode different behaviours. E.g.: 0: off 1: Mute 2: Play 3: Accent 4: Echo 5: Roll 6: Randomize 7: free for additional idea Best Regards, Thorsten.

Hi, you've to upload a firmware which supports SD Card operations, such as MIDIbox SEQ, MIDIBox NG, MIDIO128, ... These firmwares also provide special debug commands (enter "help" in the MIOS terminal), e.g. "sdcard" to get the SD Card status. Best Regards, Thorsten.

Windows... :rolleyes: Great that it's working now! Best Regards, Thorsten.

Hi, such a function isn't provided by the firmware. It will only work for the (MIDI compliant) NRPN and Pitchbender events. Actually Mackie HUI "misuses" the MIDI protocol here, therefore MBNG isn't prepared for this kind of data transfer. Wouldn't it be possible to use better protocols at your side? DAWs are very flexible today, doesn't it allow you to define your own communication scheme? Best Regards, Thorsten.

I added this request to the wish list, but the implementation won't be so easy because there are many implications in the firmware for sending NoteOn with velocity 0 to turn off the note. Changes at many places will be required, especially in the MIDI scheduler, sequencer core, live and recording function, MIDI router, etc... (just thinking loudly): it might be easier to add a "modification" option directly in the MIOS32 kernel, but SW wise it would be a dirty patch which should normally be prevented to avoid unexpected side effects in later developments. However, did you already request a firmware fix from the manufacturers of these synths? Because they don't work according to the MIDI specification. I guess that some other devices can't control these synths correctly as well. In addition, Note Off events will disturb the "running status" feature, hence you will notice some additional latency if MBSEQ would switch between Note On/Off. Best Regards, Thorsten.

I added following items to the wish list: ---------------------------------------------------------- FTS for Random Generator ---------------------------------------------------------- Selectable Button Behaviour for Step View ---------------------------------------------------------- FTS for Recording Mode ---------------------------------------------------------- Two items haven't been added because I need more input: do you mean that it should just move the step to a new position, like the UTILITY->MOVE function (where the same can be done with the rotary encoders)? Or do you mean a "tick-wise" shifting, then the delay layer is the right choice. You could use the existing Groove Pattern function for such purposes: Change to the Groove page and select a Custom groove style. At the right side you can now specify the number of steps which should be processed until the pattern repeats (in other word: it's like the LFO period) For each step you can specify a Delay, Length and Velocity modification. Especially odd pattern lengths result into very interesting variations. It has a technical reson why the FTS function won't be applied on the recorded notes: whenever notes are recorded into a step, the function needs to know which keys are pressed on the keyboard to handle the poly recording properly. It also needs to know this to generate glides. If the recorded note isn't identical with the "tracked" notes, then this mechanism wouldn't work anymore. So: I've to find a different (more complicated) way to handle this; currently I've no good idea how to do this without wasting a lot of memory... therefore it can take some time until the feature will be available. As a workaround you could just enable the FTS function for the track, this can be done in the MODE page (enable ForceScale). Best Regards, Thorsten.

With the background that the stylish part is played by SIDs, it's really cool! :-) Best Regards, Thorsten.

I'm really sorry about the trouble! :-( Currently I've no plausible explanation what is going on there with the given information. It could be that an electrical problem damaged not only the pattern, but also other (random) blocks on your old SD card, which is now leading to inconcistencies, but this is only speculation... Most important: don't store anything on the old SD card anymore! I would propose following approach: create a backup of the complete SD card (if possible) Then format it (or use the second card) Copy all files (not only a session) to the new filesystem. If this doesn't help we need to check this further with some terminal commands which I can't give you this week due to vacation... Best Regards, Thorsten.

Hi, thanks for the generous offer, but I think that I don't need a MC303 to understand what you mean (I'm working with MIDI devices since more than 25 years...). I'm not planning to enhance the Live Pattern functionality anymore, because I think that all requests are fullfilled, they are just working a bit differernt from that what you might know from other devices, opening possibilities that you don't know from those devices. E.g. a general difference to common sequencers is, that MBSEQ works on a step basis, and not timescale basis. Therefore it isn't possible to record MIDI events exactly with the entered (or automated) swing/shuffle timing. Instead this timing has to be generated while playing back the steps in the configured raster. I also think that you've missed the already existing arpeggiator capabilities of MBSEQ which are unusual (but powerful) as well. See following tutorials which are a good entry point to get a basic understanding of the workflow: http://www.ucapps.de/midibox_seq_manual_tut.html And following video shows how quick groovy and especially variant sequences can be created: Of course, somebody might think that the MBSEQ approach has limitations compared to other devices, but from my point of view I see certain advantages (especially in the flexibility such as step progression changes or non-destructive FX additions) which are not available for devices which work with the static timescale approach. So, let's say these are more like conflicts in the different approaches, but no real limitations. It might make sense to use two or three different sequencers and to sync them to get out the best of all approaches. :) Best Regards, Thorsten.

Somebody (I guess it was Wilba) requested to add these parameters for information purposes. They've no influence on the sound engine. Best Regards, Thorsten.