TK.

I think, that the initialisation of RAM variables outside a function won't work, because this requires a special SDCC specific copy routine, which copies the value from flash memory into RAM. It's located here: but I never tried it out. An easier (and sometimes less code consuming) way is to initialize global variables inside the Init() Hook of MIOS Best Regards, Thorsten.

Hi Robin, good to know, that at least the upload is working. Serge's Loader won't be maintained anymore, and I think that a more stable (and especially OS independent) implementation could be realized much easier with MIOS Studio. But this isn't planned yet... So, currently only MIDI-Ox can be used for a stable read-out Best Regards, Thorsten.

Alright, great! :) I will release this change soon. Best Regards, Thorsten.

No, I haven't any idea, the connections are really straightforward. You can simply test the module by connecting the Mi/Mo inputs of the LTC module to +5V/+0V in order to switch on/off the LEDs Best Regards, Thorsten.

Thank you very much! It was a nice party with friends and a C64 Joystick! ;-) Best Regards, Thorsten.

I'm using 0.13.3 on my Windows PC as well... just tried it on my laptop (Linux, gpasm 0.13.4) and get a different output. Strange! It makes sense to compare the listings, where the hex codes with the appr. assembly instructions are listed, but I currently haven't so much time for such checks... maybe you could try to find the differences. Best Regards, Thorsten.

Currently you are writing the output of MIOS_MIDI_TxBufferPut into the MIOS_PARAMETERx registers, this won't work, because WREG has an undefined value at this time. It's better to determine the MIDI bytes again after the entire MIDI event has been sent (just duplicate the code), to write them into MIOS_PARAMETER[123] instead of calling MIOS_MIDI_TxBufferPut. Thereafter you can call the MIOS hook. Best Regards, Thorsten.

it's really strange, I cannot reproduce it! I just tried it again in master and slave mode. I know that we had the issue that the pattern was not changed on the first song bar some builds ago, but I found the issue and solved it. Are you really sure, that you don't mis-interpret a certain "new effect", maybe related to your song settings? Could you please describe, how you've configured the song steps, and what the patterns are doing? if the patterns are properly formatted, this should not happen. It shouldn't have any effect, there is no feedback from the AOUT module to the core. just change 0x36 to 0x37, build a new .hex file, upload it, wait until all BankSticks are formatted, change back to 0x36, build a new .hex file, upload it, and have (hopefully) some more fun ;) No, the loopback cannot trigger new songs. Song changes have to be done interactively. There is one function still missing, which was available in one of the previous MBSEQ V2 releases, then replaced by another feature... but it should be available again: switching between the songs w/o turning the first encoder, but by pressing one of 16 GP buttons. Something which currently also doesn't work properly anymore, but which will work sooner or later is, that you can switch between different song parts with the GP buttons or with an external keyboard (where you have more keys available) What you are describing sounds like "push the play button and wait for one hour until the song program has finished". My focus was always interactivity and not full automation. Especially for overlapping songs I don't see a solution with the existing concepts. Only "cheap but working" solution is to prepare several parts within a song, which are started once you select them with the GP button/external keyboard, and which slightly change the pattern sets until they reach the set of the next song, and once these patterns are played, you can smoothly switch to the next song. But this will require a lot of manual preparations... You don't need to stop the sequencer, you could also mute the track and ummute it, once the event configuration has been done. My own workflow looks different: I've prepared some configurations, e.g. for MIDIbox SID, FM, for a Drum VST, for Reaktor Instruments, for other MIDI synths, and I have stored them into a seperate BankStick. These patterns don't play any events, they only contain the configuration I'm normaly using for these instruments. When I want to try out something new, I just load one of these prepared configurations, later I store the ready made pattern to another location. By doing so, I can switch to the right setup immediately and especially without unmuting a track or stopping the sequencer. In other words: these are the prepared setups for which you are looking for, and it's definitely not "less live" Program Change/Bank Selection: I've to think some days about a good solution... Delay effect: it's still in the wishlist, but also a minor feature and I think it isn't relevant for the first release. I will do such gimmicks after I finished MIDIbox SID V2 and feel boring. More important is to get MBSEQ V3 into a state, where I can ensure, that the basic concepts won't be changed anymore. Especially the BankStick storage structure should be stable (to ensure pattern compatibility within all V3 releases). There are also some features which are unusuable yet (e.g. Drum Mode) and where I have to find a solution as well, before removing it from the feature list just because I haven't found a usage concept which was good enough for live usage. I know what you mean, but I think this is not desirable, I prefer immediate response and direct control. It's not only less debugging effort and higher stability, it's especially because of the fact, that the engine has enough time to prepare the next events while other events are sent. This results into more stable timings. Here a simple example - let's say, the sequencer runs in slave mode and receives a MIDI clock. Once the first track sends a MIDI event, the sequencer has ca. 1 mS time to prepare the next event in parallel why the current event is sent. This is much more time than really required, accordingly you won't run into any non-MIDI related timing issues. If you want to prepare all MIDI events (MBSEQ V3 can play up to 64 MIDI events per step), preprocess and priorize them, the latency - especially in slave mode - will be much greater than 1 mS! Accordingly you really have to ask yourself, if it is worth the effort, or if it only leads to new compromises. Best Regards, Thorsten.

Changes in the song are always saved once you select a new song position, or exit the menu This was an error in one of the last builds, it should be fixed in the meantime. Do you notice this effect with the latest build? Nobody else reported problems with the memory yet, and I also haven't noticed this by myself in the last months. Reformatting: the easiest way is just to change the magic number in app_defines.inc - this will format the BankSticks with the next boot. Thereafter change back to the original value, so that the BankSticks will be formatted again, but for the official magic number. How do you select G2T1? Normaly I press and hold the mute button, and press the track which should be selected with one of 16 GP buttons. Thereafter I change back to the edit menu. The 17th track has been removed by the Loopback function. Just select the appr. port in the Event menu - any track can play the role of a "master" track, it's even possible to use multiple tracks for this, and to mute/unmute them. Or to use a seperate group (pattern) and only to switch this "master track pattern" while all other groups play a static pattern. It's only important, that the master track is located before the other tracks, otherwise it can happen, that a new base note should be played, but the other tracks only get it with the next step. So, best choice is group 1, track 1 It is not possible to define own layers, since many definitions are required (see seq_layer.inc) - which combinations are you missing exactly? There are three trigger layers, each can be assigned to a function in the Assign menu. E.g., Trigger Layer A to Gate, Trigger Layer B to Accent, Trigger Layer C to Roll. If this is not enough information, just wait for the documentation, which I will write in some days. Nice idea, I will add this to the Utility menu. I haven't planned to extend the possibilities of the MIDI Router. But which function are you missing? Maybe it could be easily added, but note that the MIDI Configuration menu is already completely filled - hope that your wishes don't require a new menu! This is in the "planned for a future release" list, but I've no idea, where to store this information, and how to allow the user to select the program change. It's also not clear to me, if it makes more sense within a pattern, or within a song. And at least I don't know, if it is really an important feature, where it makes sense to spend some hours to realize it (I wouldn't use it by myself), or if this is just one of those ideas of the type "I'm missing something what I saw in another sequencer" This seems to be a bug. But it could also be related to your BankStick issues. Best Regards, Thorsten.

You are right when saying, that this circuit is not ideal for all type of LEDs, and if the matrix should be used for other purposes than for the sequencer. Here my hope is, that the community improves the circuit and especially tests and writes documentation in the Wiki. For myself the situation is a little bit relaxed. The LEDs don't consume that much power, and in general there are never more than 8 green + 1 red LED driven by a 74HC595 at one moment. Yes, the output driver of a single pin is overdriven, you can notice this by measuring the voltage - it's not 0 anymore, but ca. 1V (out of spec). Thats the reason, why there are seperate "cathode" pins for the buttons. These are just duplicates of the LED outputs which drive proper 0V/5V. Just to highlight it again: please improve this circuit, test it and publish the documentation! It will save effort at my side. I don't really want to take care about everything... Best Regards, Thorsten.

Just forward the bytes to USER_MPROC_NotifyReceivedEvent, the function header describes where the bytes are expected... Best Regards, Thorsten.

Hi Chris, you don't need to compare them, the notify function tells you exactly which pin has been changed. You only need to forward the value which has been changed. In other words: it's not required to send all values on any change. Best Regards, Thorsten.

Build #64 is now available which comes with some important changes: o a utility menu has been implemented which contains a lot of new useful functions - you can enter it by pressing the F1 button - Copy: copies the currently selected track into a buffer - Paste: copies the buffer content into the current track - Clear: clears the current track - Move: so long the appr. button of this function is pressed, the edit page will be displayed, and steps can be moved with the encoder below the step It should be self explaining once you try it out! :) - MuteAll: mutes all tracks and jumps to the Mute page - Save: quick access to the save menu (formerly F1 function) - Rec: quick access to the record menu (formerly F2 function) o the F2 button now switches between the Step 1-16/17-32 view This was previously only possible by doubleclicking a track button [/code] The utility page has some free slots for future extensions.

From my point of view this project is finished, it was just a toy, and I don't use it by myself... However, this project is open source, maybe somebody else feels motivated to program such a feature? Best Regards, Thorsten.

Could somebody who built a MB64E please answer the questions? Best Regards, Thorsten.

Hi, so long you only want to send common MIDI events, the appr. code can be added very easily to the main.asm file: ;; -------------------------------------------------------------------------- ;; This function is called by MIOS when an button has been toggled ;; Input: ;; o Button number in WREG and MIOS_PARAMETER1 ;; o Button value MIOS_PARAMETER2: ;; - 1 if button has been released (=5V) ;; - 0 if button has been pressed (=0V) ;; -------------------------------------------------------------------------- USER_DIN_NotifyToggle ;; check for control surface buttons - the CS handler will jump ;; back if the button has not been assigned to a CS function goto CS_MENU_BUTTON_Handler CS_MENU_BUTTON_Handler_Return ;; Ok, button not assigned to CS, send a MIDI Note event movlw 0x90 call MIOS_MIDI_TxBufferPut movf MIOS_PARAMETER1, W ; button number addlw 0x18 - 4 ; add 0x18 (C-1) - 4 (first four buttons assigned to CS) call MIOS_MIDI_TxBufferPut movlw 0x7f ; send velocity=0x7f when button pressed, 0 when button depressed IFSET MIOS_PARAMETER2, 0, movlw 0 call MIOS_MIDI_TxBufferPut return [/code] The CS buttons should be assigned to DIN 0..3: [code] #define DEFAULT_DIN_MENU_EXEC 3 ; menu exec button assigned to DIN pin #3 #define DEFAULT_DIN_MENU_RIGHT 2 ; menu right button assigned to DIN pin #2 #define DEFAULT_DIN_MENU_LEFT 1 ; menu left button assigned to DIN pin #1 #define DEFAULT_DIN_MENU_SELECT 0 ; menu select button assigned to DIN pin #0 Best Regards, Thorsten.

Hi Michael, what is the output of "gpasm --version"? Best Regards, Thorsten.

Hi, yes, of course, diodes are required whenever buttons are connected together to a matrix. You can find them in the schematic as well: http://www.ucapps.de/mbhp/button_duoled_matrix.pdf just use any "general purpose" diode, e.g. 1N4148 The direction is important! The additional button/LED options are documented in the CHANGELOG.txt: 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) and 3 additional buttons and LEDs for the trigger layers A, B, C and 1 additional button and two LEDs to switch between step 1-16/17-32 The pin assignments are made in mios_tables.inc (or within the setup_*.asm file) PLEASE NOTE: these buttons/LEDs are optional and could be added for a more comfortable usage in case that somebody creates a new frontpanel. The same functions are also accessible in following ways for people who already built a MBSEQ (e.g. V2) - Selecting group: can by cycled with F4, track can be directly selected by holding Mute button and pressing the appr. GP button 1-16 The selected group is visible in most menu pages - Selecting trigger layer: can be cycled with F3, the selected layer is only visible within the edit page - Switch between Step 1-16/17-32: can also be done with F2, or by doubleclicking a track selection button o added optional LEDs for Play/Stop/Pause [/code] Best Regards, Thorsten. /EDIT: step 1-16/17-32 button/LEDs now available

Hi John, the list about functions which are not fully implemented, or which need improvements is only in my head ;-) Just add your comments to the MBSEQ V3 talk thread Best Regards, Thorsten.

Hi Chris, when you add: movlw 0xb0 call MIOS_MIDI_TxBufferPut movlw 0x10 call MIOS_MIDI_TxBufferPut movlw 0 ; first analog pin call MIOS_AIN_Pin7bitGet call MIOS_MIDI_TxBufferPut movlw 0xb0 call MIOS_MIDI_TxBufferPut movlw 0x11 call MIOS_MIDI_TxBufferPut movlw 1 ; second analog pin call MIOS_AIN_Pin7bitGet call MIOS_MIDI_TxBufferPut [/code] your Joystick will send CC's Best Regards, Thorsten.

Hi Robin, short note: I haven't tried out the BankStick upload/download feature for a long time, I'm not so sure if it really works anymore. I will check this in the next days Best Regards, Thorsten.

The move step function has been improved in build #63, and now we have also a marker which points to the active step. I will create a new Utility page, from where such functions (and some more) are accessible, because I think that moving steps is not only useful for recorded tracks. Here a video which demonstrates how much fun it makes :) http://www.youtube.com/watch?v=mSG_GgWkaB4

I've changed the description to make this more clear: Just push and hold the "Move" function in the save page (GP Button #7), and turn on the encoder below the step which should be moved. It should be self explaining once you try it out! :) [/code] And I've created a video to demonstrate, how much fun it makes: :) http://www.youtube.com/watch?v=mSG_GgWkaB4 I will create a new Utility page, from where such functions (and some more) are accessible, because I think that moving steps is not only useful for recorded tracks. Best Regards, Thorsten.

Build #62 contains a new function which is based on an idea from Rio: o added "move step" function to the record menu - it could also be useful for normal track editing (w/o recording) Just push and hold the "Move" function in the save page (GP Button #7), and turn on the encoder below the step which should be moved. It should be self explaining once you try it out! :)

I'm not 100% sure, but I remember that I had some issues with bit copies like this one: what happens, when you display the PORTE value directly on screen? E.g., within the DISPLAY_Tick() function Best Regards, Thorsten.