MIDIbox SEQ: next attempt

[TK.]

Here a snapshot of the current hardware:

Due to the physical dimensions of the displays, I've to change the panel layout. It doesn't fit on a 19" panel anymore, so I will possibly take a small children's keyboard for the case ;-) If somebody has alternative ideas for the panel layout, don't hesitate to publish your layout here

I've also replaced the two MIDI In/Out LEDs by two additional buttons (can't get enough).

The 2*40 LCDs are not the final ones (I've to wait until Reichelt sends me the second backlit LCD), these are just two cheap displays w/o backlight from EBay for 5 EUR

Best Regards, Thorsten.

[arumblack]

SIL909 I have supersequencer dreams, but at the moment i do not think i have the skilles to get them to reality. I am attending school for EE, but i am only in my first semester, and have not even an EE class yet. Stuill i would love to help anyway i can, from concepts and later on when i have a better idea what is going on, design and implementation.If you think i could be of any help, or would just keep me informed that would be great.

perhaps we should start a new thread to discuss this topic.

[pay_c]

If somebody has alternative ideas for the panel layout, don't hesitate to publish your layout here

Yeah, I´m on it. I will definitely make it 19" rack compatible (like all my designs up to now - it´s so damn practical), but I´m still not sure, which buttons I´ll use. For a first step: You could move the MODE triggers in the middle of those two LCDs (right between Button 8 & 9). Then move those free assignables to the left side (or other ones).

Should make up some room for 19" stuff...

[Marcel]

If a second team designs a 16 track sequencer which plays the events directly from EEPROM, this method could be taken into account. The difficult task is to implement the editing facilities. Here the Zyklus manual could give useful informations.

Best Regards, Thorsten.

P.S.: I'm a big fan of your Sidologie album, especially of Knucklebusters - it's my personal Remix of the Year :-)

Hi Thorsten,

I'm very happy to hear you like the CD, thank you ;D

As soon as I get the the Zyklus' manual I will forward it onto you and/or post it on a website as there may be other people interested in getting to learn its features. There may be some very usefull parts in it that could be implemented without too much hassle.

In any case, I'll keep you posted on this one :)

Cheers,

Marcel

[pay_c]

Question: What encs did you use, TK? Where to order them?

[Guest Anton_sigl]

:) Oh what tha hell, this thing is much cheeper (Part price) and for live sets very handly -best work ever seen :D

[TK.]

The encoders are presents from Ian Hurlock and D2K :-)

The middle ones are from the china deal (see http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=parts_q;action=display;num=1051948494;start=0#0)

The resolution is poor (MIOS_ENC_MODE_DETENTED2), but on the other hand they are perfect for controlling note values. I'm using them with following speed settings:

        movlw   3 ; predefined speed
        movwf   MIOS_PARAMETER2
        movlw   MIOS_ENC_SPEED_FAST     ; fast mode
        movwf   MIOS_PARAMETER1
        movf    TMP1, W                 ; encoder number
        call    MIOS_ENC_SpeedSet

so that values can be changed from 0 to 127 with a single fast turn (270°), and  incremented by +/-18 per revolution with a slow turn The one at the right side is a panasonic encoder (see http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=news;action=display;num=1060000023) Like Dan wrote: the response is excellent! Setup: MIOS_ENC_MODE_DETENTED and

        movlw   2  predefined speed value for datawheel
        movwf   MIOS_PARAMETER2
        movlw   MIOS_ENC_SPEED_FAST     ; fast mode
        movwf   MIOS_PARAMETER1
        movlw   DEFAULT_ENC_DATAWHEEL   ; encoder number
        call    MIOS_ENC_SpeedSet

Best Regards, Thorsten.

[DrBunsen]

Once again, TK breaks new ground!  This setup looks fantastic for live sequencing.  

I would have to second the comments above about shuffle - I have a 707 and use it in my live setup, and it definitely adds to the groove.  I'd like to suggest finer adjustment than the 707 allows though, because the steps between amounts of shuffle are too high, and the highest shuffle settings are too drastic.

There's only two other things I'd like on my Santa wish list: tap tempo and flam as described at http://www.retrosynth.com/ah/search/lookit.cgi?-v9705.1068.  I realise that either of these might require some tricky programming.

Keep up the good work guys, I look forward to more news on the Supersequencer.

[TK.]

Hi,

DrBunsen: I will do what I can (and what the PIC18F is able to do ;-))

ok, here some news: although the code is very modular now, I noticed that the performance of the SEQ_CORE is much better than expected. The worst case processing time I measured was about 150 uS (microseconds!) when all 4 tracks are playing arpeggios simultaneously. In the last days I only made some small additions to the user interface (ca. 50% is implemented), but mostly was busy with tweaking on some nifty sequences (see also the bottom of this posting) - to check the usability and to get some ideas which features make the editing easier. Sometimes I'm also changing some previous concepts, e.g. in the meantime there is a 3rd version of the arpeggiator which is now more understandable, resp. more intuitional than the versions before

Once the user interface is ready, I will think on features like Morphing (no problem), Grooves (needs some evaluation) and Chains (...of pattern), and so on...

Concerning the chain mode: with some cut backs it could be possible to play 4 patterns at the same time, in other words: to play 16 tracks. Drawback: only one pattern can be hold in the edit buffer and modified live, the other 12 tracks have to be played directly from BankStick. A good compromise for a simple step sequencer, isn't it? :)

Ok, and here some impressions about the current design state (I don't work daily on it, only when I have some sparetime and feel motivated, so I cannot say you anything about the date of the first release):

Some panel views (will be enhanced by more views):

Ok, and here some auditable results for people who maybe don't know what they can expect from a simple step sequencer :)

Very experimental (the original is about 3 hours long, but I forgot to record it ;-)), many Fx have been added, some of them are also controlled from the MBSEQ via CCs. all patterns made with MBSEQ and recorded with Logic whenether they worked (means: the MBSEQ doesn't play the whole song - yet)

http://www.midibox.org/midibox_seq/mbseq_v2_demo1.mp3

Just an arpeggiator test, nothing more - edited within 5 minutes, played some random chords and took the best ones ;-) Only the lead sound is controlled from MBSEQ (you hear the MIDIbox SID in action :)), the drums are comming from my Groovebox which acts as MIDI clock master in this example.

http://www.midibox.org/midibox_seq/mbseq_v2_demo2.mp3

Best Regards, Thorsten.

[arumblack]

Hey looks great....

"Concerning the chain mode: with some cut backs it could be possible to play 4 patterns at the same time, in other words: to play 16 tracks. Drawback: only one pattern can be hold in the edit buffer and modified live, the other 12 tracks have to be played directly from BankStick. A good compromise for a simple step sequencer, isn't it?"

definitely. one question, would you be able to switch the pattern in the edit buffer with one playing from the bankstick without interuption of the song? ( i am guessing no on this? ) still totally awesome if you can't.

"Ok, and here some impressions about the current design state (I don't work daily on it, only when I have some sparetime and feel motivated, so I cannot say you anything about the date of the first release): "

I feel you on that, and i must say you get a hell of a lot of work done for a spare time project. I started my sid in october and i still don't have it working yet, maybe if i'd have just ordered the boards instead of trying to make my own, but i am stubborn. and i was warned....but another batch of parts is in the mail today so soon......soon.

[TK.]

It will be possible to switch between different patterns and to edit them during a performance w/o timing problems.

But it won't be possible to save the changes w/o timing problems.... thats the limitation of the BankStick

Best Regards, Thorsten.

[pay_c]

My oh my oh my. Looks & sounds just great (you could bring the first example out on record if you tweak it a little more - sounds awesome up to now!!).

Does that mean that the Control Surface will keep like that now? (Then I would start designing it (I´ll try a 2HE design - perhaps that´s possible) and to get the first parts)

Awesome, just really do love it! In my opinion, this is the best app of UCApps up to now!!!  :D

[TK.]

Thanks PayC :)

Please wait with the Control Surface until all features are implemented. I change my concepts from time to time (remember the concept one month ago?). However, I guess that most of the hardware will be used for the final one, but I could add some more buttons and LEDs (e.g., for the chain mode I definitely want to add a Forward, Rewind and Pause button), and I will rearange some buttons of my current boards

Btw.: the MIDIbox SEQ is grooooooovin' now :D

With 4 times the common MIDI clock resolution (384 ppqn)

Example:

http://www.midibox.org/midibox_seq/mbseq_v2_demo3.mp3

(Bass drum is played on Track 1 w/o swing, HiHats are played on Track 2, Swing is varied from 1 to 16)

Makes fun...

Does anybody know other grooving styles? (from the mathematical point of view?)

Best Regards, Thorsten.

[arumblack]

I didn't get to listen to those demos last nite(had to be quiet as everyone was sleeping...) but i checked them out just now and, wow! good stuff goin on!

Will definitely have to try this one out too....(but, defintiley later, after other projects are finished.

[DrBunsen]

Will there be enough space (or even be an option at all) to change the code (by myself, i know you don't need it TK) to a 16 track sequencer? 4 tracks is by far not enough for me.

Or aternatively, could you daisy-chain extra cores from the one control surface, and press a button to choose which one you are editing, like you do with the multi-SID?  Perhaps by importing the necessary code from the SID app?

/edit/  I just noticed someone else already suggested that, and then the discussion moved on to using banksticks.  Which would be simpler to build/ more powerful in use?

This project is looking very good TK!!

Hear hear!  I just listeded to your groove example above Thorsten....  YAY!  Thanks and well done.  How are you editing the groove; is it continuously variable with an encoder?

(BTW a friend of mine makes and sells the "Swingchroniser", a MIDI/DIN master clock with a big knob on the top that *just* applies groove - that's all the box does.  He seems to sell quite a few of them)

After reading http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=misc;action=display;num=1074705442, I began to think about drum editing.   Would it be possible to have a drum edit mode in the SEQ, which would work something like the good old x0x.  

One track's "Note" layer sending different MIDI (drum) notes out on the same channel from the exisiting:  the existing 16 LEDs and buttons  for display and note entry, and a way of selecting which drum voice is displayed.

An encoder could be used to sweep through the different drum names (=note numbers) on the LCD.  The pattern for that voice pops up on the LEDs.  A quick way of muting each note number/pattern would be great.  Layers 2 and 3 remain for CCs, velocity, etc, which would be global across all drum voices (ie code unchanged)

I realise that you might not want to work this into the existing code TK as it might not be what you need for your own use, but in your opinion how much code work would it take, and would there be room?

[TK.]

Hi,

as I already wrote, the MBSEQ will finally provide 16 tracks, but only 4 which can be edited live. The others are played directly from EEPROM. Switching between different patterns (e.g. during Song mode) won't affect the timings, but writing into EEPROM - thats the only limitation. However, for live playing it's cool to have some additional tracks (e.g. Arpeggios or transposed CC sequences) in background, normaly you won't edit them all at the same time during a performance. And in the (home)studio - when preparing songs - it doesn't matter...

Of course, MBSEQ can also be daisychained and synchronized via MIDI clock. Every core can run standalone without control surface - so, every additional core gives you 16 additional tracks.

Groove: yes, the groove parameter is continuously variable and can be changed with the datawheel. The tracks never get out of sync when changing the groove parameter in realtime (this was the most difficult part, but finally solved). Groove works also with external clock, the MIDI clock will be quadrupled by some kind of software implemented PLL (phase locked loop).

I've prepared 16 different groove styles, but currently only "shuffle" is implemented. I need your input (mathematical formulas) for more different styles.

Thanks for the suggestion for drum editing, I will think about this. In fact everything is prepared for such features, becaue it would also mean to introduce a new layer type, which then has to be assigned in the "Layer Assign" menu. There is also enough room for such features, only problem is my available sparetime. ;-)

Maybe important to say this: I'm planning an initial release in some days which will provide the most important features and which will especially support all the hardware options, so that people (who like beta version adventures) will have concrete informations about the hardware and can begin with building their boxes.

This version won't support all features which I've agreed  here. Not because the implementation would be impossible or difficult, but because I've already a lot of effort to documentate the project and need to decide which functions are really essential for a first release, and which could be programmed and documented later.

Only after the initial release I can tell you, which features can be added, to the main version, which could be provided as alternative option, and which have to be programmed by somebody else.

When you follow the MIDIbox SID project, you know that "planned feature" can mean: sometimes you've to wait for one day, sometimes for 6 months, sometimes for one year or more... ;-)

Best Regards, Thorsten.

[Steven_C]

This is the first time I've looked at this thread, and I can't beleive what I see! I think this project will become a bit of a legend!

I think the best stuff comes about when people's hearts are in it, not companies wallets! What we see here is really an artform!

I like Thorsten's dynamic approach to create the most user friendly tools (which are also works of art!) is the best, not limited to the design brief limitations that companies come up with!

truly works of art!

BTW, TK decided not to part with those 2x40's after all! (for those who have good memories  ;))

cya, from steve

[DrBunsen]

as I already wrote, the MBSEQ will finally provide 16 tracks, but only 4 which can be edited live. The others are played directly from EEPROM.

Oh OK so there would be no advantage in using extra COREs then

Groove: yes, the groove parameter is continuously variable and can be changed with the datawheel.

Double YAY!

Groove works also with external clock

!!!!!!!!

Thanks for the suggestion for drum editing, I will think about this.

Bitte schoen!

I'm planning an initial release in some days ... will have concrete informations about the hardware and can begin with building their boxes. ... I've already a lot of effort to documentate the project ...

Only after the initial release I can tell you, which features can be added, to the main version, which could be provided as alternative option, and which have to be programmed by somebody else.

Of course, and most grateful for the superhuman effort so far.  Above and beyond the call of duty.  I recently scored two 2x40s at a good price, so I will be keen to start on my box, get learning on the operations and on the code too, and perhaps to help in future with new features.

Thanks for looking at all our suggestions TK,

DB

[DrBunsen]

I hope you're not sick of all my questions yet  :)  I just have one more, I promise ...  

I've started another thread for those people interested in pursuing radically different sequencer paradigms: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1075654854 so you can be left in peace to finish your funky garoooove SEQ  ;D

 With 16 tracks it wouldn't be possible to store the whole  pattern in RAM. ...  it makes realtime editing via MIDI impossible. Most parts of the control surface handler would have to be changed ...  The whole SysEx store structure would have to be changed  ... a second JSynth GUI would be required ... realtime editing with JSynth wouldn't be possible

... It is possible to chain multiple MBSEQs (synced via MIDI clock), but it isn't possible to control them from a single control surface (it would have to save all editable parameters in RAM anyhow)

Please forgive if I am misunderstanding, or missing something obvious;  it sounds like

1. there's not enough RAM left in the PIC to handle 16 tracks in realtime with one CORE, and

2. there's not enough CPU overhead to handle slave COREs in the SID fashion.

So in the SID (I think?) the "master" CORE is interpreting all the actions of the control surface, and handling the LEDS, LCDs and MIDI.  The "slave" COREs only have to respond to MIDI and operate the SID board.  That is why a 16F PIC can handle it.

Would it be possible though to physically switch the control surface from one SEQ to another?  With a hardware switch to disconnect the DIN and DOUT lines from CORE1 and connect to CORE2.  

Whichever CORE is connected to the CS can be edited, while the other(s) continue to play whatever groove they have stored, without change.

Or would the hardware/software choke on this and bring the beats to a grinding halt?

I ask this because I am planning to build my system in a fairly modular way, like the suggestions here http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=concepts;action=display;num=1062210038;start=1#1 and it seemed a natural progression.  Excuse my ignorance please if it is not possible ...

[TK.]

You've mixed some informations here. I will try to explain it in detail.

there's not enough RAM left in the PIC to handle 16 tracks in realtime with one CORE

This is wrong. There is enough RAM to handle 16 tracks, and the timings are extremly stable. Stable means here, that the SEQ kernel never needs more than 1 mS in worst case to handle all 16 tracks at a clock event (I optimized the routines by viewing the timeslices with a scope). This worst case happens on every 16th step, means: every 107 mS @ 140 BPM

The sub ticks are consuming about 200 uS --- so, CPU power is really no issue (for comparison: I measured a jitter of ca. 2 mS when Logic Audio plays a MIDI track, regardless if I'm using my Hammerfall DSP MIDI Out, MIDIsport 2x2 MIDI Out or MBHP_USB MIDI Out, so this must be a problem with Windows...)

To give you an expression: here is the data structure for one track record:

;; -----------------------------------
;;  track record structure
SEQ_TRKSTATEx           EQU     0x00
SEQ_TRKMUTED0x          EQU     0x01
SEQ_TRKMUTED1x          EQU     0x02
SEQ_TRKPLYTICKx         EQU     0x03
SEQ_TRKSTEPx            EQU     0x04
SEQ_TRKPOSx             EQU     0x05
SEQ_TRKQUEUE0x          EQU     0x06
SEQ_TRKQUEUE1x          EQU     0x07
SEQ_TRKQUEUELx          EQU     0x08
SEQ_TRKEVNT0x           EQU     0x09
SEQ_TRKMODEx            EQU     0x0a
SEQ_TRKDIVLENx          EQU     0x0b
SEQ_TRKASSGNx           EQU     0x0c
SEQ_TRKTRANSPx          EQU     0x0d
SEQ_TRKGROOVEx          EQU     0x0e
SEQ_TRK_RESERVEDx       EQU     0x0f
SEQ_TRKRECORD_LAST      EQU     SEQ_TRK_RESERVEDx

As you can see, one track allocates exactly 16 bytes, and so it wasn't a big deal to instanciate 16 of them which are working independent from each other. RAM consumption: 256 bytes

;; -----------------------------------
;; Live Editing Tracks
SEQ_TRK0            EQU      0x200
SEQ_TRK1            EQU      SEQ_TRK0 + 1 * SEQ_TRKRECORD_LENGTH
SEQ_TRK2            EQU      SEQ_TRK0 + 2 * SEQ_TRKRECORD_LENGTH
SEQ_TRK3            EQU      SEQ_TRK0 + 3 * SEQ_TRKRECORD_LENGTH

;; Tracks played from EEPROM
SEQ_TRK4            EQU      SEQ_TRK0 + 4 * SEQ_TRKRECORD_LENGTH
SEQ_TRK5            EQU      SEQ_TRK0 + 5 * SEQ_TRKRECORD_LENGTH
SEQ_TRK6            EQU      SEQ_TRK0 + 6 * SEQ_TRKRECORD_LENGTH
SEQ_TRK7            EQU      SEQ_TRK0 + 7 * SEQ_TRKRECORD_LENGTH
SEQ_TRK8            EQU      SEQ_TRK0 + 8 * SEQ_TRKRECORD_LENGTH
SEQ_TRK9            EQU      SEQ_TRK0 + 9 * SEQ_TRKRECORD_LENGTH
SEQ_TRK10            EQU      SEQ_TRK0 + 10 * SEQ_TRKRECORD_LENGTH
SEQ_TRK11            EQU      SEQ_TRK0 + 11 * SEQ_TRKRECORD_LENGTH
SEQ_TRK12            EQU      SEQ_TRK0 + 12 * SEQ_TRKRECORD_LENGTH
SEQ_TRK13            EQU      SEQ_TRK0 + 13 * SEQ_TRKRECORD_LENGTH
SEQ_TRK14            EQU      SEQ_TRK0 + 14 * SEQ_TRKRECORD_LENGTH
SEQ_TRK15            EQU      SEQ_TRK0 + 15 * SEQ_TRKRECORD_LENGTH
SEQ_TRK_END            EQU      SEQ_TRK0 + 16 * SEQ_TRKRECORD_LENGTH-1

But there is also some other kind of data, and these are the RAM consuming layer informations. Every track consists of three layers, assigned to the first MIDI byte (e.g. the Note number or CC#), the second MIDI byte (e.g. the Velocity or CC value) and the gatelength.

;; -----------------------------------
;; pot layer A
SEQ_POT_VALUES_A_00     EQU     0x1c0
        ;; ...
SEQ_POT_VALUES_A_3F     EQU     0x1ff

;; -----------------------------------
;; pot layer B
SEQ_POT_VALUES_B_00     EQU     0x080
        ;; ...
SEQ_POT_VALUES_B_3F     EQU     0x0bf

;; -----------------------------------
;; pot layer C
SEQ_POT_VALUES_C_00     EQU     0x0c0
        ;; ...
SEQ_POT_VALUES_C_3F     EQU     0x0ff

You can see: 4 tracks * 3 layers * 16 steps makes 192 bytes

Also the control surface requires some bytes, and the basic sequencer functions. With MIOS you've 896 bytes free for an application (with some tricks ca. 128 bytes more) --- but this is not enough for storing the layers of the remaining 12 tracks in RAM.

So my solution was (and I haven't taken it into account before, therefore I refused the 16 tracks requests first...) to read the layer informations of the other tracks directly from EEPROM.

The resulting use case:

• every pattern consists of 4 tracks
  
• you can play 4 patterns at the same time
  
• you can edit only one pattern w/o timing problems
  
• you can switch between the patterns w/o timing problems
  
• you can connect multiple cores together and you can send patterns to another core, so that it will be played from this slave in sync with the master
  
• and now the limitation: when saving a pattern in EEPROM, the sequencer engine will stall for about 100 mS, this is an audible effect and not desired during a live performance. On the other hand: this doesn't hurt when you are using prepared patterns, modifiying it during the sequencer is running but don't want to save the changes...
  
• for the records: when a song switches to 4 different patterns, it takes ca 10 mS and is therfore not audible (the switching is synchronized with the sequencer engine, it will happen automatically at the end of a sequence when no note is played). I achived this performance by implementing a new MIOS function "MIOS_BANKSTICK_ReadPage" which will be part of the next MIOS version (MBSEQ uses a copy of this function, so that it will be compatible with the current MIOS version).
  

2. there's not enough CPU overhead to handle slave COREs in the SID fashion.

A sequencer is not a synthesizer ;-)

But like you can read above, it's easy to send a pattern to another core, so that it plays this pattern (if you really need more than 16 tracks...)

Would it be possible though to physically switch the control surface from one SEQ to another?  With a hardware switch to disconnect the DIN and DOUT lines from CORE1 and connect to CORE2.  

Whichever CORE is connected to the CS can be edited, while the other(s) continue to play whatever groove they have stored, without change.

Please explain me exactly which advantages you are expecting from this method.

Which workflow is your target?

There are a lot of enhanced methods to make such a sequencer more powerfull, you could either use external SRAM (e.g. 128k, battery buffered - I already wrote how to realize this), or you could implement a bidirectional interface between multiple cores, so that the master can request and submit informations from/to the slaves (-> see the companion core concept). This works fine so long as it is guaranteed that the slave can handle a request without much delay. And here is the problem --- the delay: I guess that a slave is always so busy, that a latency of less than 100 uS cannot be ensured --- so, forget the parallel core concept with bidirectional transfers, it doesn't really help.

If you are thinking on an alternative sequencer concept, then maybe a sequencer which doesn't work step-based? Ok, such a sequencer definitely desires more RAM -> think about an external RAM extension

Or you are thinking about a step sequencer which isn't so flexible like MBSEQ, but is optimized for dedicated jobs (e.g. a drum machine) -> don't use 3 layers, but think about another data format to save the step information. For example, you could run 32 tracks in parallel, every track assigned to a single note, velocity and gatelength. You only want to control the "mute status" and "accent". Result: instead of allocating 32 tracks * 3 layers * 16 steps = 1536 bytes for the layer information, you would only need 16 bit * 32 = 64 bytes for the accent flags plus 3 * 32 = 96 bytes for the note/velocity/gatelength which is used for the whole track (mute flags are already stored in the track record)

Ok, I think this is enough to give you some impressions about the art of system programming ;-)

Best Regards, Thorsten.

[DrBunsen]

 

So my solution was (and I haven't taken it into account before, therefore I refused the 16 tracks requests first...) to read the layer informations of the other tracks directly from EEPROM.

The resulting use case:

    every pattern consists of 4 tracks

    you can play 4 patterns at the same time

    you can edit only one pattern w/o timing problems

    you can switch between the patterns w/o timing problems

!!!!

Please explain me exactly which advantages you are expecting from this method.

Which workflow is your target?

What I was thinking:

Start with 4 tracks, build up a nice pattern with the CS, then when you have that pattern worked out, leave it running and switch the CS to another 4 tracks (different MIDI instruments) to build up another layer on top.  The original 4 tracks just play away in the background as a backing while you improvise over the top.  If you switch the CS back to edit the original pattern, the new one is locked and continues to play.  Whether in one or multiple COREs doesn't matter to me.

It sounds like this is what you have achieved already.  I'm impressed. ;D ;D ;D

Ok, I think this is enough to give you some impressions about the art of system programming ;-)

For sure!  Thanks very much for the hints.

[Phattline]

Hi, a maybe stuped question but i´m not a programmer:

I am on the way to built a MB64 and a duluxe Sequ

The Ain´s on the sequencer are free that means 64 Pots for a Sequencer with integratet MB64 (e.g.only pots), I tell this question, beause when I have 2 Midiboxes I need a Midimerger thats means more money.

The same Question by SID with integratet MB64 (e.g only 64 Pots)

Is it possible or are the Firmwares to differnt?

[TK.]

In theory you could add some code to the applications in order to send CC values with the pots, but this solution won't never be so comfortable like the MIDIbox64 application. So - in consideration of your missing programming skills - it's easier for you to use a seperate core module.

There is no need for an external Merger, just enable MIDIbox Link (see also http://www.ucapps.de/midibox_link.html). You can select the merger options in the menus (or from external) - connect the MIDIbox64 before the MIDIbox SEQ, select "MBLink Forwarding Point" in the MIDIbox64 menu, and "MBLink Endpoint" in the MBSEQ menu - voila!

Best Regards, Thorsten.

[TK.]

I've changed the panel design of MIDIbox SEQ - it's still not final, but much more changes are not planned.

http://www.ucapps.de/midibox_seq.html

Best Regards, Thorsten.

[der.warst]

Well this is just plain amazing, :P

I guess since something like this is stated in the announcement, i will be able to control an analog synth with this one. This would be great because I've ordered a Simplesizer-PCB some days ago and was looking for something suitable to play it.

My plans so far are: building both devices into one housing to have a combination of  real analog Synth and analog style Seq for maximum live usability as well as the possiblity of using it to trigger other devices.

Would it be possible to also use the AOUT of the MB64 SEQ as MIDI to CV/Gate converter to be able to play live on a MIDIkeyboard in combination with the Seq or would this be too much?

Hope you come up with a final part list soon, so I can start ordering.

Greetings,

der Warst :