TK.

You are right, so let's set 256 steps as limit. And for parameter/trigger layers 16 maximum Selection: press A or B button to select between the first and second layer (as before) press C button to select 1 of 16 layers with GP buttons (LCDs will show the available layers + names) Best Regards, Thorsten.

So, you mean that each directory should contain a script with additional instructions - no problem :) This would also force the user to sort patches into the correct subdirectories. This could be the content of a file, located under /SysEx/MIDIboxSID # configurable parameters (?1..?8) # changable with GP encoders ?1 = Device ?2 = Bank ?3 = Patch # request strings (the name shouldn't be longer than 40 characters) :MIDIbox SID Edit Buffer request = F0 00 00 7E 4B ?1 01 08 00 00 F7 subdir = Patches :MIDIbox SID Patch request = F0 00 00 7E 4B ?1 01 00 ?2 ?3 F7 subdir = Patches :MIDIbox SID Ensemble Buffer request = F0 00 00 7E 4B ?1 01 78 00 00 F7 subdir = Ensembles :MIDIbox SID Ensemble request = F0 00 00 7E 4B ?1 01 70 00 ?3 F7 subdir = Ensembles [/code] etc... Best Regards, Thorsten.

Picture of a MBHP_CORE_STM32 module (layouted by Nils) behind the MBSEQ frontpanel (layouted by Wilba):

I like this idea, as I see the need for my own synths as well - therefore you can be sure that a powerful solution will be available - sooner or later :) I guess, that it is acceptible if SysEx request strings are stored in a .txt file on SD Card? Which means, that I don't need to provide editing capabilities - just create a .txt file which defines the parameters of your synth, store it on the SD card, and load the file into MBSEQ. Thereafter the predefined SysEx request strings can be sent from a special page, and received SysEx data can be recorded and stored on SD Card into a special library directory. Which means: you would also be able to maintain the library with your PC (e.g. for backup reasons, or to copy a large bulk of already existing .syx files) Best Regards, Thorsten.

Some words about the progress: meanwhile the infrastructure (MIOS32) is available and running stable. I started to rewrite the MBSEQ application completely in C. My plan is to implement a MBSEQ V3 equivalent first (so that I'm able to compare the performance, code size, etc.. with the old implementation), before continuing with new V4 functions. But in background new concepts are already in use. E.g., the timestamped MIDI events, a generic MIDI port interface, different task/interrupt priorities to simplify multitasking, abstract hardware layer to allow accurate realtime emulation on a Mac, later maybe also for other operating systems (if implemented by anybody else) E.g., it's already possible to play tracks in Master and Slave mode. The Mac based emulation can sync to the real hardware, and vice versa - there is no better test to check the robustness :) Meanwhile I've also a better feeling about the new possibilities of the STM32F103RE controller (which only costs. ca. US $15 btw.) and can give you some answers to your feature requests: Integrated Sampler: no - although I was already able to generate a stereo waveform through a I2S audio DAC at 48kHz, this task loads the CPU so much, that the sequencer wouldn't run stable anymore. Use an external sampler, or your PC (which allows more comfortable editing) Touch screen: feasible, but expensive hardware and high programming effort. Different sequences of different length at the same time: already possible since MBSEQ V1, MBSEQ V4 will support a configurable number of steps which is only limited by the pattern memory (more than 1024 steps per track is feasible!) Number of layers: configurable, only pattern memory will limit the number of parameter layers, more than 16 layers per track is feasible Number of tracks: at least 32, maybe more. There will be a separation between drum and synth tracks to save memory usage. The user interface will behave different if a drum track is selected - in other words: on a drum track, it will behave like MB-808 (e.g. it will provide A/B/C/D sections), on a synth track like MBSEQ V3 loading more than 4 tracks into ram: since MBSEQ V3 all tracks are in RAM and directly editable, this won't change in MBSEQ V4. Only MIDI files will be directly played from SD Card, and are only editable by importing/exporting the file. However, main focus is a live sequencer (playing .mid files is only an add-on), and this won't change. DMX output: feasible with external IIC device SEQ scratching: available since MBSEQ V2 via "Scrub" button, but worked only in forward direction. MBSEQ V4 will support backward direction as well. Bigger LCDs/graphical LCDs: feasible, but not in my focus (e.g. I don't want to buy expensive hardware and spend hours in programming just to satisfy requests which are not interesting for myself). However, thanks to the C implementation and different API layers, anybody else could provide such an option later MIDI over LAN: MIOS32 will support an TCP/IP layer (in future). The MIDI layer allows to send MIDI event packages to the TCP/IP layer... accordingly MIDI over LAN will be feasible. Even WIFI will be possible, although you won't like the latency Layer to vary the time intervals between the steps: will be part of the new integrated groovestyle editor Midi processors for internal routing... with midi fx... LFOs and midi filters....: thanks to the new timestamp concept: feasible w/o much effort More random stuff... rotate....skip closed gates ... random move active gates selected and or random chance by percent: feasible, as number of trigger layers will be enhanced as well (only limited by pattern memory) Nameable drum maps: feasible Integrated Mackie Control emulation: feasible (a C based demonstrator which runs on MBSEQ already exists for PIC, there is enough flash memory free to install this application in STM32 as well, so that no additional code upload will be required) Midi sync. delay calibration.. Clock sync delay in ms... from say -30 ms to +30 ms: positive delays are feasible thanks to the new timestamping concept. For negative delays, just compensate the delay on your other sequencers. enhanced mixer functions: feasible (also in conjunction with MIDI Fx) Support for 16 motorfaders or "Stribes": feasible, although I think that Phattlines additional ideas should be implemented by somebody else (high programming effort) Tempo track: feasible Button/LED matrix with more LEDs/Buttons: feasible, e.g. 64x64 = 4096 LEDs/buttons shouldn't be a problem if you find place for such a monster Animation on the matrix display, like tenori-on?: open source allows you to integrate such functions MIDI Fx: Delay, feedback velocity, feedback note, feedback gate time, feedback clock: feasible MIDI Fx: CC LFO and ADSR: feasible Access to button/encoder functions via CC/SysEx, so that external MIDI controllers can enhance the CS: it's just an enhancement of the exising MIDI remote concept, therefore feasible REC Monitor: already available in MBSEQ V3 why not implement a sort of korgs KARMA or things from the LATRONIC NOTRON sequencer: feasible, but very high programming effort Possibility for more IIC MIDI: feasible, but not really useful as discussed earlier. MIOS32 supports up to 8 IIC_MIDI modules Recording start message when the sequencer starts and a recording stop message when the sequencer stops: MIDI clock start/stop will do this job - already available since MBSEQ V1 Is it possible to make a one shot pattern with MBSEQ V4: feasible would also like to have a option to sample each note after another from a synth, like this software does: if a software already exists, I don't see the need for re-inventing the wheel (in which menu should such a feature be burried...? and who would really use it?) is the memory organisation hardcoded or a dynamically?: it's dynamic and configurable Or 512 step (32 BARS OH MY GOD): as mentioned earlier, number of steps is only limited by available SRAM. E.g., a drum track could consist of more than 100000 steps if you don't play any other track ;) Btw.: the word "feasible" doesn't mean, that I commited to integrate requests into the firmware by myself... Best Regards, Thorsten.

Hi, mkmk.pl is obsolete - the new programming platform is completely based on already existing Makefiles And it works well on a Mac :) Where did you found a reference to this expired script? From where did you download the skeleton package? Did you already install gputils and sdcc? Best Regards, Thorsten.

I've still 8 GM5 chips in stock from people who haven't paid yet (4 weeks after first notification, 1 week after deadline...) So - this is your chance to get the remaining ones, the quantity doesn't matter - 1, 2, ... 8. I've also more than 100 small PCBs in stock - let me know if you are interested as well (the rest will be sold during the next bulk order). Just PM me the desired quantity - NOW! - first come, first serve! SOLD OUT! Best Regards, Thorsten.

It was my idea to change the layout this way. Initially I found the small font used for code frames unreadable, during my modifications I found out, that background colour can be changed as well, and this was the result MIOS is a text adventure. >[/code] However, if some people are not happy with the choice, I can change the colours again, Best Regards, Thorsten.

Easy: CS_M_UTILS_RotateLeft CS_M_UTILS_RotateRight Best Regards, Thorsten.

Wilba already added extra buttons which are sufficient for customisation, e.g. F1-F4 are now assigned to dedicated buttons (means: they are free for custom assignments), Copy/Paste/Clear could be assigned differently if you don't need this function so often (they can also be quickly accessed in the Utility menu), and Up/Down buttons are more or less redundant as well. For the case that somebody understands your question wrong: the MBSEQ V4 handling will work perfectly even with the old V2 panel (I'm using on my own MBSEQ) Best Regards, Thorsten.

Welcome on board! :) I cannot recomment to connect MBSEQ thru a BCR2000. USB-MIDI interfaces of some Behringer devices are unreliable, and I guess that it will also add some unwanted latency and especially jitter which leads to unstable clock timings. I would propose to use a GM5 based interface instead - I don't want to promote Ploytech, but so far I haven't seen any other MIDI interface in the past 15 years which works so stable and with such a good performance. The price (for the midibox.org community) doesn't speak for itself - because they could sell the chip for 100 EUR and it would still be worth the money! Best Regards, Thorsten.

It's implemented: o it's now possible to send MIDI start events to external sequencers while MBSEQ is running. This allows you to re-synchronize them with MBSEQ if they have been stopped (e.g. to select a new pattern on these devices), or if they are playing at a different tempo. The "SEQ_BUTTON_ExtMIDIStart" function can be assigned to a dedicated button (e.g. you could replace the Metronome function if not used), but it's also accessible by pressing MENU + METRONOME button. By default, the MIDI start event will be sent at the first step. It's possible to select a different step by pressing MENU + METRONOME + one of the GP buttons (step will be displayed by GP LEDs). Pressing MENU is not required if the function is assigned to a dedicated button. To evaluate this function, try following steps: - connect a MIDI sequencer (or synth. with sequencer function) to your MBSEQ and configure it for MIDI slave mode. - go into MIDI menu and ensure, that MIDI clock is enabled for all OUT ports which should send the MIDI start event (+ a MIDI clock) - press PLAY button of MBSEQ - the external sequencer should start to play as well. - now stop the external sequencer - (change a patch, sound, or whatever...) - press MENU + METRONOME: the external sequencer should start once MBSEQ reaches the first step. Another try: - both sequencers are playing in synch. - press MENU + METRONOME; Hold METRONOME - press a GP button to select the step at which the external sequencer should restart[/code] The feature to send a MIDI start event based on the currently visible step will be available with MBSEQ V4, as it requires a different way how to handle MIDI events (timestamping required, as MIDI start has to be sent *before* MIDI clock) However, the V3 solution is already quite useful. :) The sources are already available in the repository, prebuilt binaries will be released soon. Best Regards, Thorsten.

It's implemented: o now the MIDI remote function can also be activated via CC, e.g. with a footswitch controller. The desired CC number has to be configured in setup_*.asm (search for DEFAULT_MIDI_REMOTE_CC) This function is disabled by default to avoid evtl. clashes with your existing MIDI setup.[/code] The sources are already available in the repository, prebuilt binaries will be released soon. Best Regards, Thorsten.

Hey, this is finally a great idea! :) So: pressing the "external start" button will send the MIDI start event once the currently visible track reaches step #1 (the track which is/was visible while triggering the button - you can switch to other tracks thereafter...) Pressing & holding this button allows you to select a different step which will trigger the MIDI start event. "currently visible track" means: dividers and progression parameters will be taken into account! Just select the track which is used as a "reference" for your external gear. The button function will be available in the Utility page, but it will also be assignable to a dedicated button. Best Regards, Thorsten.

There are people who are trying hard to emulate this nice distortion :) -> http://bel.fi/~alankila/c64-sw/ Best Regards, Thorsten.

Could you please try if this quick hack is working at your side: http://www.ucapps.de/tmp/midibox_fm_v1_1d_rc1.zip I added a new SysEx command, but have no time to test it completely (e.g. check if storing instrument 2..4, drumsets/ensembles is working) from the documentation: d) F0 00 00 7E 49 <device> 0A <type> F7 Stores back the current patch into EEPROM/BankStick Can be used if no Control Surface is available - parameters can be changed via CC or SysEx <device>: device number 00-7F <type>: 00: Stores patch of Voice #1 01: Stores patch of Voice #2 02: Stores patch of Voice #3 03: Stores patch of Voice #4 10: Stores drumset 70: Stores ensemble setup [/code] Best Regards, Thorsten.

Hi, all OPL3 registers + MBFM sound engine parameters are stored in RAM, they can be transfered into a BankStick by calling the MBFM_BANK_StoreP function, which is located in src/mbfm_bank.inc ;; -------------------------------------------------------------------------- ;; Stores a patch from RAM in EEPROM or BankStick ;; IN: Instrument Number in MBFM_CURRENT_INSTRUMENT ;; Patch Number in MBFM_PATCH ;; Bank Number in MBFM_BANK ;; -------------------------------------------------------------------------- MBFM_BANK_StoreP [/code] How would you like to trigger this function? - via a button directly connected to the PIC - via a button connected to a DIN pin - via a MIDI event - via SysEx Currently, this only works via the control surface function (you have to go into the Save menu). Usually I prefer this laborious approach, as it prevents unintended store operations on HW issues (e.g. no DIN connected and somebody forgot to mount MBHP_CORE:R9, or random CCs are received from an external MIDI device...) But so long you know what you are doing, and provided that your HW runs stable, nothing prevents you from adding a dedicated possibility to trigger the store function. Only question: how do you want to control the bank and patch number, how do you want to differ between the instruments, and how do you want to store drum and ensemble parameters (MBFM_BANK_StoreD and StoreE)? Best Regards, Thorsten.

Panel number #00000002 up&running! I built it within two evenings, and I must highlight, that it was really a pleasure. It's extremely robust, and in distance to my breadboard based solution, there is no trouble with sticking the buttons/LEDs through the frontpanel holes, as everything fits perfectly! Well constructed, Wilba! :) Best Regards, Thorsten.

Adding an external sync function will be easy. Adding the possibility to define the bar position at which the MIDI Start event should be sent will be difficult, as I don't know, at which page the value should be configurable - any (realistic) idea? Best Regards, Thorsten.

1/2 Channels??? You should see 5 MIDI IO Ports if J1/J2/J3 are connected to ground (default) If you only see a single MIDI IO Port regardless of the J1/J2/J3 selection, check that Pin #25 is properly connected to ground. If you are unsure, solder Pin #25, and #5/#6/#7 again Best Regards, Thorsten.

-------------------------------------------------------------------------- MidiTest Results -------------------------------------------------------------------------- ================ Info ==================================================== Date: 23 Nov 2008 Time: 23:42:26 AppVersion: 4.6.231 OS: Microsoft Windows XP Professional, Service Pack 2 (Build 2600) Processor(s): Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Speed: 2394 MHz Number: 2 API: MultiMedia Extensions (MME) Test type: Advanced Use timestamp: yes Errors: None ================ Tested Message Types ==================================== Note off: yes Note on: yes Key aftertouch: yes Controller: yes Program change: yes Channel aftertouch: yes Pitchbend: yes System exclusive: yes MIDI time code quarter frame: yes Song position pointer: yes Song select: yes Tune request: yes MIDI clock: yes MIDI tick: no Start: yes Continue: yes Stop: no Active sensing: yes System reset: yes System exclusive mixed with realtime messages: no ================ Ports =================================================== MIDI Output: MIDIbox SID (1) Description: midibox.org GM5 Provider: midibox.org DriverDate: 11-20-2008 DriverVersion: 1.0.6.0 MIDI Input: MIDIbox SID (1) Description: midibox.org GM5 Provider: midibox.org DriverDate: 11-20-2008 DriverVersion: 1.0.6.0 ================ Results Per Message ===================================== MESSAGES Snd Rcv Snd+Rcv Message TotalTime: 1505.28 ms 23994.51 ms 25499.79 ms Message MaximumTime: 0.25 ms 2.21 ms 2.26 ms Message MinimumTime: 0.03 ms 0.00 ms 0.03 ms Message AverageTime: 0.05 ms 0.77 ms 0.82 ms SysexTime: 19.44 ms 2640.01 ms 2659.45 ms SysexAverage: 0.00 ms 0.26 ms 0.27 ms < 1 ms: 31250 22455 21219 1 - 2 ms: 0 8732 9953 2 - 3 ms: 0 63 78 3 - 4 ms: 0 0 0 4 - 5 ms: 0 0 0 5 - 10 ms: 0 0 0 10 - 20 ms: 0 0 0 20 - 50 ms: 0 0 0 50 - 100 ms: 0 0 0 > 100 ms: 0 0 0 Message count: 31250 Sysex count: 160 Sysex size: 10000 Sysex passed: 10000 Message latency: 0.82 ms Total time: 75.497 sec Message jitter: 0.39 ms Message max deviation: 1.44 ms ================ Results Per Byte ======================================== BYTES Byte TotalTime: 9956.80 ms Byte MaximumTime: 1.46 ms Byte MinimumTime: 0.02 ms Byte AverageTime: 0.32 ms < 1 ms: 31223 1 - 2 ms: 27 2 - 3 ms: 0 3 - 4 ms: 0 4 - 5 ms: 0 5 - 10 ms: 0 10 - 20 ms: 0 20 - 50 ms: 0 50 - 100 ms: 0 > 100 ms: 0 Byte count: 79569 Byte latency: 0.32 ms Byte jitter: 0.15 ms Byte max deviation: 1.15 ms [/code]

It means, that CS1/2 of the core are connected to the left GLCD, and CS3/4 to the right GLCD If you would use a 240x64 display, you would have to connect all 4 CS lines to a single GLCD (because in fact such a GLCD consists of four KS0108 controllers) Best Regards, Thorsten.

Ploytec released the GM5 Windows driver for midibox.org as an early christmas present for you: http://www.ucapps.de/mbhp_usb_gm5.html (if you don't find it at this page, click the refresh button of your webbrowser) It helps to overcome many flaws of the Microsoft legacy driver - it's multi client capable (you can run MIOS Studio and your DAW/MIDI Programs in parallel), transfers large SysEx bulks correctly, has much less latency when events are sent over multiple ports, and allows you to name the IO ports. Have fun! :) Best Regards, Thorsten.

Cimo: but this is what I'm doing to ensure consistency in the detailed documentation! (and thats the reason why I normaly ommit to create additional docs) I'm asking for a better description, because as a programmer I'm blind - I don't know why this description which already exists in the setup_*.asm file causes such misunderstandings as you can see in the schematic enhancement created by indeep. From http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fsequencers%2Fmidibox_seq_v3%2Fsetup_mbseq_v3.asm ; ========================================================================== ; In this table all button functions are mapped to the DIN pins ; ; The function name can be found on the left, the shift register and pin ; number on the right side. ; ; SR/pin numbers: ; SR = 1 for the first DIN shift register ; SR = 2 for the second DIN shift register ; ... ; SR = 16 for the last DIN shift register ; ... ; SR = 17 for the first DIN shift register of optional "misc. button matrix" ; ... ; SR = 24 for the last DIN shift register of optional "misc. button matrix" ; ; Pin = 0 for the D0 input pin of the shift register ; Pin = 1 for the D1 input pin of the shift register ; ... ; Pin = 7 for the last input pin (D7) of the shift register ; ; Set the SR and pin number to 0 if a button function should not be used ; ; The table must end with DIN_ENTRY_EOT! ; ========================================================================== [/code] So - where is the error? Which detail is missing? Best Regards, Thorsten.

Everything answered in the lounge... since it's a section only for programmers, you have to be logged in to read it! http://www.midibox.org/forum/index.php/board,37.0.html Best Regards, Thorsten.