TK.

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.

We need a term which can be easily shortened to a meaningful 3 or 4 character acronym. Therefore "Jam" is probably the best choice :smile: Patterns: my intention was to store them in the /SESSIONS/<name>/MBSEQ_C.V4 file (contains various local configuration parameters) Naming and separate files are too much overhead (this would especially affect the load time of a session for not so much value behind this approach). Format will be something like: # Num Gates Accent LivePattern 1 *............... ................ LivePattern 2 *.......*....... ................ LivePattern 3 *.......*....... *............... This way you can share patterns in postings on a textual basis, and users can just integrate (and re-arrange) them into a session with the text editor of the MIOS Filebrowser Best Regards, Thorsten. P.S.: I will be on vacation the next days, and come back to this topic in ca. 2 weeks

So, neither DIN nor DOUT is working - could the problem be located at the core module? Best Regards, Thorsten.

You are right. The term "performance" could be miss-leading for the page, here I see more the role of the mute, pattern and/or song page. Other proposals? In this new version the pattern selection has been separated for drum and common tracks (I guess that this is what you mean): -> http://www.ucapps.de/mios32/midibox_seq_v4_088_pre14.zip Are 16 patterns sufficient? At least it seems that LPC17 can still handle this, but RAM is almost completely allocated now and I hope that there are no stack overrun issues. Anybody with a LPC17 core ready for testing the integrity? (if all sequencer functions are still working?) Best Regards, Thorsten.

I found the AINSER64 resolution bug and fixed it in this version: http://www.ucapps.de/mios32/midibox_ng_v1_033_pre6.zip Here a usage example: http://svnmios.midibox.org/filedetails.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fcontrollers%2Fmidibox_ng_v1%2Fcfg%2Ftests%2Fainserhq.ngc Best Regards, Thorsten.

Ok, understood - needs more discussion the other day ;-) I couldn't resist to consolidate the Record, Live and Repeat page for a more ergonomic usage of the new functions. This should also solve the channel confusion and different recording usecases: -> http://www.ucapps.de/mios32/midibox_seq_v4_088_pre13.zip What is new: the Live and Repeat page have been removed. Instead we've now some subpages in the recording page for the different use cases: Left side: Track selection, Record on/off and Forwarding (previously called "Live") on/off The "Step Record" configuration is selected and showed at the right side (starting with Mode) Whenever this subpage is activated, step recording takes place. If any other subpage is selected, live recording is used instead. (e.g. step recording doesn't make sense together with the Pattern function - one possible confusion solved ;-) The live page enables live recording, and allows to select Mono/Poly, Auto-start and quantisation. The new pattern page used for pattern based recording (and playing) If a drum track is selected, individual patterns can be assigned to the Drum instrument selected with GP9 (or played from the keyboard). If a common track is selected, GP9 allows to switch between Mono/Poly mode instead. Copy/Paste are possible with GP15 and GP16, but also with the dedicated buttons if this subpage is selected. The MIDI configuration page is similar to the page that we know from MENU->MIDI We've 4 busses, each bus can either be assigned to control the T&A function (Transpose and arpeggiator), or the Recording function (which is used for MIDI forwarding as well - previously called "Play Live") The dedicated Recording Port/Channel has been removed, instead the same port, channel, keyboard zone is used like for the forwarding function. The misc page provides the remaining parameters for the forwarding function (Octave transpose, optional Fx and Force-to-Scale) Hope that I haven't broken too much with the changes ;-) Best Regards, Thorsten.

Such as the MBSEQ V4L? ;-) Here a new version which supports recording - now the serious fun begins! :smile: -> http://www.ucapps.de/mios32/midibox_seq_v4_088_pre10.zip Again some limitations (it's only a quick&dirty hack to check the possibilities and blocking points): - live pattern recording should work flawlessly for drum tracks - it sometimes doesn't work correctly for common tracks if chords are played (the mechanism needs some logic to add/remove notes while key is pressed) - recording mode can be enabled in repeat page (it's the same function which is available in record page) - you can switch to EDIT page for visual check of the recorded pattern - required recording configuration: -- Rec Port/Channel have to match with Live Port/Channel; Fwd.Midi should be enabled -- if drums are recorded, one of the parameter layers (e.g. LayA) should be set to Velocity in the MENU->EVENT page (e.g. instead of Roll which is the default) It seems that I've to overwork the Rec/Live port & channel configuration. Actually they should be the same (I don't remember why I differentiated in the past...) Best Regards, Thorsten.