MIDIbox NG Concept

[TK.]

Meanwhile I've a clear vision how the upcoming MIDIbox NG project should look like.

It will replace the PIC based MB64, MB64E and MBLC projects by a technical up-to-date and especially more flexible approach in the hope that even newbies without programming skills will be able to customize the controller for their needs. :)

Specs: http://www.ucapps.de/midibox_ng.html

I'm open for discussions - implementation will start in December (however, most of the routines are already available since they are part of MIOS32 or unreleased applications) - therefore the first beta version will probably be available before christmas. :santa:

Best Regards, Thorsten.

[Antix]

Hi,

Probably I am ridicolous with this question as I am not in "HARD" programming but I would ask the same:

as the new core has more power is it possible to drive displays like Hitachi SX14Q004 or something like ?

and manage the touch also ?

It would be nice for a controller

Thanks and best regards

Antix

[Hawkeye]

Thanks for your work and time on this :clover:

I am already loving the planned support for the LED-Ring Board and the thought of adding a second SRIO chain for even more Blinkenlights :-).

Don´t know, if it is too much asked, but maybe we could add a generic framework for synthesizer patch retrieval, modification/storage and push-back?

I.e. to program and provide a better UI for the hundreds of available hardware retro synths from the 80s and 90s and 00s :-).

Many greets,

Peter

[TK.]

Probably I am ridicolous with this question as I am not in "HARD" programming but I would ask the same:

as the new core has more power is it possible to drive displays like Hitachi SX14Q004 or something like ?

and manage the touch also ?

It would be nice for a controller

definitely not intended.

To make this clear I added following topic to the "Known Limitations" section:

> no support for big GLCDs, no support for touchpanels. Re-inventing Lemur, an iPad or similar tablet PC is out of scope.

> However, second-hand iPad1s are cheap today, and you could connect to the MBNG via OSC

Don´t know, if it is too much asked, but maybe we could add a generic framework for synthesizer patch retrieval, modification/storage and push-back?

I.e. to program and provide a better UI for the hundreds of available hardware retro synths from the 80s and 90s and 00s :-).

Already considered! :)

> Storing/Restoring snapshots of the configuration (e.g. to use the controller as synth programmer with patch storage)

> SysEx receiver/dumper to store and "fire" SysEx dumps to/from SD Card

you will also like this one:

> "Morhp" function to fade smoothly between two snapshots

Best Regards, Thorsten.

[jojjelito]

Thanks for working on this! :clover: Santa is coming to town :santa:

Edit: Removed things which won't be a problem.

Edited November 1, 2012 by jojjelito

[Duggle]

Will it be possible to have a *large* number of LCD's?

I've always felt that every control element needs a programmable label to identify it and give feedback as to it's current state.

An example might be an array of 64encoders with a 2*40 LCD for every 4,6, or 8 knobs, that's a total of 16, 12, or 8 LCD's. I will surely build such a sick puppy!

[V`cent]

Sysex+NRPN (incl nonstandard) support ? :)

[Antix]

Multiple display are "sexy" and affordable as a 16x2LCD on ebay is very cheap.

In addition , multiple displays remind me of some old synthesizers.

If possible I would also like this opportunity.

Regards

Antix

P.S.

I wanted quote Duggle but my computer is acting up this morning :rofl:

Edited November 1, 2012 by Antix

[TK.]

Will it be possible to have a *large* number of LCD's?

I've always felt that every control element needs a programmable label to identify it and give feedback as to it's current state.

An example might be an array of 64encoders with a 2*40 LCD for every 4,6, or 8 knobs, that's a total of 16, 12, or 8 LCD's. I will surely build such a sick puppy!

Yes, it will be possible to connect up to 8 CLCDs or GLCDs.

And it will be free definable how and where "control elements" (buttons/encoders/pots) output messages.

Example for a minimal controller:

Sysex+NRPN (incl nonstandard) support ? :)

Receiving & sending SysEx and NRPN will be supported.

E.g. I'm planning to create a programmer setup for Waldorf Blofeld (SysEx), and I will also create a setup for sammichSID (NRPN) :)

Best Regards, Thorsten.

[V`cent]

Awesome ! :)

Will it be possible to send "negative" values via nrpn ? (Essentially just Alesis/Akai f*cking with anyone trying to make a editor for their products)

+changing the type of data sent?

Apparently Alesis/Akai have managed to deviate quite a bit from the standard, not limited to :

"MIDI insists MSB is sent for 7 bit NRPNs

Alesis seemed to assume LSB is sent. As a programmer, this makes sense ... BUT it isnt the midi standard.

MIDI insists NRPNs are unsigned 14bit

Alas, again Alesis insisted on using a "signed" 14bit

therefore value ranges like [-100, 100] are really [16284, 16383] [0, 100]

most hardware interpets this as [0,100] ... [16284, 16383]

Which results in either a large gap in the middle (not very practical)

or, since most will not over/underflow to only choice is to use 2 controls,

one for the -ve range, one for the +ve range."

[Antix]

Programmer setup for Waldorf Blofeld ? :drool:

Definitely I need it.

So little GLCD will be implemented

something like this?

http://www.zyscom.pl/katalog/ym12864c.pdf

a KS0108 based GLCD

Regards

Antonio

[TK.]

Will it be possible to send "negative" values via nrpn ? (Essentially just Alesis/Akai f*cking with anyone trying to make a editor for their products)

No problem, I can provide signed and unsigned format + the desired min/max range.

Apparently Alesis/Akai have managed to deviate quite a bit from the standard, not limited to :

"MIDI insists MSB is sent for 7 bit NRPNs

Interesting, from where did you get this information?

I only own an older version of the MIDI spec (v4.2) which doesn't clearly specify the value format. It gives the master tuning RPN as an example, where the value is located in the MSB, and the LSB is declared as "don't care" - but the spec doesn't say that this rule should also be applied on custom NRPNs

However, thanks for the hint anyhow!

When potential differences are considered during the first implementation, enhancements (even more exotic formats) will be a no-brainer in future. :)

So little GLCD will be implemented

something like this?

http://www.zyscom.pl/katalog/ym12864c.pdf

a KS0108 based GLCD

Yes, all displays which are listed at the MBHP_LCD page are supported. :)

Best Regards, Thorsten.

[jojjelito]

Cool cool!

I own a Roland XV-5080 which is a bit like like a JV-xx, only with more sounds. I hope it will be possible to define your way of editing patches/banks/rhythm sets. There's a great page that explains the somewhat convoluted hierarchy employed by the JV-90, most likely all JVs, XVs, Fantoms and "new Jupiters"/Integra etc. It would be interesting if it was possible to define text lists on the SD-card with default patch/wave/drumkit names for the various expansion boards since some of these synths address these cards depending on the slot the card is installed in. That way it would become possible to load sysex, change the destination card slot to fit your particular synth and upload it.

I haven't looked, but I assume that there's a similar story for Yamaha Motifs, Korg Tritons, Kurzweils, Ensoniqs and E-mu boxes from the 90's onward. If someone was ambitious he or she could make a programmer for an MR-Rack, a Fantom-XR, a Motif-XS or... Well. Lots of work :frantics:

[V`cent]

No problem, I can provide signed and unsigned format + the desired min/max range.Interesting, from where did you get this information?

AWESOME! <3

Now, I got this information while researching the Miniaks apparently really zany Midi/NRPN spec, so it's not guaranteed information (Hence the quotes around the entire block) :/

There generally seems to be a cr*pload of "undocumented/meh, let's just do it our way" going on with a lot of things that are Midi related.. Blarhg.. :(

[TK.]

There generally seems to be a cr*pload of "undocumented/meh, let's just do it our way" going on with a lot of things that are Midi related.. Blarhg.. :(

I agree!

Also at other places the (30 years old) MIDI spec is sometimes not precise enough and gives too much room for interpretations, which then results into complex software which has to consider many special cases.

Best Regards, Thorsten.

[rvlt]

Hi TK,

I just read the part where the MB-NG is used for a DIY keyboard. Does that mean that the planned (direct) controller-support (pots, encoders, switches..) for the MB-KB project is stopped?

If so, is there a technical reason for it or is it just an economic decision (save development resources)?

How would you link the two cores? Simply via midi (bi-directional) or is there another way?

cheers

Lars

[ilmenator]

I just read the part where the MB-NG is used for a DIY keyboard. Does that mean that the planned (direct) controller-support (pots, encoders, switches..) for the MB-KB project is stopped?

I'm not TK but I can say that reading just a part will more often than not get you things in the wrong way. So, no, it is not stopped, in fact most of it is already there.

[tonedef]

Hi TK,

I just read the part where the MB-NG is used for a DIY keyboard. Does that mean that the planned (direct) controller-support (pots, encoders, switches..) for the MB-KB project is stopped?

If so, is there a technical reason for it or is it just an economic decision (save development resources)?

How would you link the two cores? Simply via midi (bi-directional) or is there another way?

cheers

Lars

I'm not TK but I can say that reading just a part will more often than not get you things in the wrong way. So, no, it is not stopped, in fact most of it is already there.

Maybe I read something wrong (or I'm just ignorant)... but the confusion to me is that the MB-KB appears to have a plan for functionality that overlaps the MB-NG quite a bit. So for people who just want a custom keyboard controller with a fist full of knobs and buttons, what are the limitations in the MB-KB (assuming a future ver. supports 128 pots + a bunch of DIN/DOUTs), that would necessitate building a MB-NG to go with it? Is it just fewer DIN/DOUT's, or something else?

Either way I'm stoked that the MB-NG is out soon! The news has finally got me off my ass to drill my panel. This will be the best Christmas present :) Thanks TK!

[Duggle]

I'm also not TK, but would think that seeing the functionality of the KB interface is working (and well by the looks) that the interface is reasonably modular and can be included with various midibox configurations with different benefits and trade-offs.

I get my 2 Keybeds (61 keys) from the local Doepfer agent next week. Cant wait to build my custom dual manual keyboard!

[Antix]

Hi,

The comment of this video says about MIDI feedback so the controller at program change receive the status of the controlled

values ( hope I have understand ).

can be a good idea implement a similar feature ( if not yet implemented ).

Mine are only proposals , are not requests , I can imagine the effort to do a similar job :smile:

Best regards

[novski]

Hi TK

I don't see the MBnet in the list of Planed Features. Why?

best regards

novski

[sineSurfer]

Hi TK, quick question:

will we be able to use MIDIbox NG with a SMT32 core?, just found out I have a spare one, while looking for the gm5 pcb hehee.

Laters!

[TK.]

I just read the part where the MB-NG is used for a DIY keyboard. Does that mean that the planned (direct) controller-support (pots, encoders, switches..) for the MB-KB project is stopped?

If so, is there a technical reason for it or is it just an economic decision (save development resources)?

Some parts of MBNG can be re-used in the MBKB later, but it has to be considered that adding additional DIN and DOUT registers will affect the scan rate for the keyboard, therefore it's probably not a good idea if you really want a "high quality" solution.

However, depending on the outcome of the second SRIO chain investigations it might be possible to scan the keyboards independent from remaining DINs/DOUTs, and this will definitely help for using MBKB as a controller - but I won't start this before MBNG is (almost) finished.

Btw.: no problem to add MBHP_AINSER64 modules to MBKB, because this module has already a dedicated interface.

How would you link the two cores? Simply via midi (bi-directional) or is there another way?

simply via MIDI IO

Maybe I read something wrong (or I'm just ignorant)... but the confusion to me is that the MB-KB appears to have a plan for functionality that overlaps the MB-NG quite a bit. So for people who just want a custom keyboard controller with a fist full of knobs and buttons, what are the limitations in the MB-KB (assuming a future ver. supports 128 pots + a bunch of DIN/DOUTs), that would necessitate building a MB-NG to go with it? Is it just fewer DIN/DOUT's, or something else?

You are right, it makes sense to merge the MBNG and MBKB project in mid-term (but not for the first release)

I updated http://www.ucapps.de/midibox_ng.html accordingly (the MBKB topic is now sorted under "Features/Specs under evaluation")

I will consider an independent scan rate from the beginning, because this has also other advantages: LED rings can be serviced faster, this makes them brighter :)

The comment of this video says about MIDI feedback so the controller at program change receive the status of the controlled

values ( hope I have understand ).

Yes, this will be required anyhow if MBNG is used as a programmer.

I've added this topic to the spec

I don't see the MBnet in the list of Planed Features. Why?

is it really required?

Anyhow, I added CopperLAN to the evaluation list.

The company got already a MBHP_CORE_LPC17 module to test the communication between MIOS32 and the Copperdiono :)

will we be able to use MIDIbox NG with a SMT32 core?, just found out I have a spare one, while looking for the gm5 pcb hehee.

Yes! :)

(because my MBLC works with a MBHP_CORE_STM32 as well, and I will also test MBNG with the MBSEQ hardware)

Best Regards, Thorsten.

[novski]

Anyhow, I added CopperLAN to the evaluation list.

The company got already a MBHP_CORE_LPC17 module to test the communication between MIOS32 and the Copperdiono :)

Well i didn't meant the conection between other sources.

What i mean is to connect a LPC17_Core to an other LPC17_Core (or some other midibox equipment...) so i can save the 4 MIDI Ports for Connection to 4 MF_NG Modules and Connect to 32 Faders... :thumbsup:

As it is writen on the ucapps.de site:

The MIDIbox Network concept is the basis for linking multiple Core Modules in the upcoming MIDIbox SID V2 project, and it will replace the MIDIbox Link which was used in the previous version.

Are those taughts buried already?

have a nice sunday!

[kelargo]

How many encoders will this have? (Re: Control surface PCB for 16 encoders/LEDrings Bulk Order)

Thanks.