sharing lcds and buttons between different midibox applications

[jrp]

Do you think there is a reasonable way to do this?

I´m planning a seq3 and two midibox cvs.

Since the cvs don´t need to be configured often, since it should all be housed in one box, share one psu, since lcds are expensive, since panellspace is limited, i had the idea to share one of the 40*2 lcds, two buttons and an encoder from the seq.

Have a button to switch them to one of the midibox cvs when i need to configure them.

Only way i can think of is to use lots of transistor switches or and gates…

Don´t know if it´s reasonable or even possible.

It would certainly lead to a lot of soldering, but if it´s managed i imagine this to be very handy.

What do you think about this?

Can a lcd be driven from a transistor switch instead of the core itself?

Is there a more elegant way than soldering 60 transistors (16 for the lcd, 4 for the buttons * 3 core modules)?

How about cmos and gates?

Say we look at the first pin of j15. It goes to an and gate. The outputs of 3 andgates (from the three first j15 pins of the three cores) are diode ored with a pulldown r and drive the lcd.

Would lead to 15 quad and gates. Also quite some effort, but the frontpanell would be much more handy - and that´s what counts in the long run!

[jrp]

took another look at the core schematic. For the lcd only 11 of the 16 pins need to be switched.

no need to switch power, ground, brightness.

Still that doesn´t change the general problem…

Ok, the easiest would be to have a configuraten for the cvs that rarely needs changing. Guess that´s the case for most users, but i´m not sure about that.

Then it´s within reason to open the box from time to time when something needs to be adjusted,

and switch the connectors by hand. no soldering, no cost.

[ptitjes]

Maybe that will sound stupid… but why don’t you:

• Connect your three core via CAN (the SEQ being the master)

• Modify the SEQ app to handle two new *SHIFT* buttons that would transfer encoder and buttons value changes to one of the two slave core ?

Or something like this… That way you have no funky hardware switching between your cores.

My 2 cents. Regards, Didier.

[stryd_one]

Seq runs on a 4620, no CAN…

Switching would go crazy if the LCD was not completely idle…

If you’re building two MBCV’s, that will take a lot of money for components and a lot of panel space for IO, I don’t think it’s worth messing about like that just to save a couple of bucks and a couple of inches… just my 2c

[jrp]

Thanks for your thoughts.

Well, it´s not about saving a buck really. It is about handling and panel space (and design, maybe). Just like the way those seq3s look.

My ios will be on the back, propably on a single connector. This is a studiosetup mainly, the connections i like to patch will be available as bananajacks on my modular synth.

But i had another thought. Is it possible to save the settings of a midiboxcv as sysexdump?

Programm and save the configurations i use and store them on the computer. Then i can remove the lcd, complete the whole unit and restore my settings via midi.

[stryd_one]

I thought that too but I don’t know about the MBCV from experience and am a bit busy to check the code… Anyone know?

[Sasha]

I read somewhere long time ago that is planing LC emulation on MBSEQ platform. That could be really useful.

[MRE]

This could easilly be solved by a PIC set up as a ‘terminal’

It would take the LCD inputs from both units on two of its ports.

A small three position toggle would tell it which port to pay attention too.

So the PIC would transfer the data from the selected input port out to the LCD. You could also save a few pins with a bit of crafty programming on the output side so that your control buttons and LCD both take up less then 9 pins. (example, the LCD could be ran in 4 bit mode, even though Midibox thinks it is attached to an 8 bit mode LCD.

The PIC would have to ignore config data from the Midibox and do the LCD configuration on its own.

You may still want to do some glue logic up front to save io pins..  an 877 has a lot of io, but still…

An example might be to tie the midibox LCD output to a shift register, then you only need two (?) wires from the midibox LCD to the PIC..

Likewise, the encoder data going back could be feed to registers (sort of the OPPOSITE of how a din module works).

Heck if you do it that way, and you only had two or three devices to control, you might even be able to do it with a much smaller PIC.

Call it a Midibox config terminal if you will…

A similar project idea was demonstrated to connect a ‘terminal’ to multiple microcontrollers in a distributed processing project..

There is a disadvantage:

after switching to the next device, you need to force a resend of screen data. (in fact, the LCD will still display the last screen, as if it was attached to the previous device [unless you write a page that says “switching to…”])

The new device was effectively being ignored, so screen data is lost untill you start watching it.. it may be in a menu location, or asking for data.. you need to force a refresh by ‘doing something’..  that ‘something’ might not be what you want.

Now, you could always dedicate an input in Midibox to act as a ‘refesh request’..  when the PIC switches to a new device, it toggles that input..  then its up to Midibox OS to recognize it and redraw the display.

[MRE]

of course a fully terminalized front end is easilly possible as well..

That would reduce all IO between the Midibox and menu surface to a serial stream and only two wires.. you would actually have MORE I/O available to the core module.

(again, you need a micro here)

But it also requires rewriting some of the core software.. including ‘breaking’ the LCD port routines… and a few more cycles are needed out of the core to bitbang the serial in and out. (BUT, you could trim some core code now as well, since it not longer has to deal with control codes and LCD initialization.)

The terminal micro is no longer simply shuffling data from one side to the other, so it is going to require more programming on the part of the builder. It has to initialize the LCD (which the first suggestion had to do as well).  It also has to handle Serial events, depacket the data, format the screen, write data to it, handle key input events, packet them to serial data, and send it out.

my first suggestion was essentially a ‘dumb switch’ with some intelligences written in to smoth out the wrinkles.. The terminal app is an intelligent device and requires a lot more programming effort for both the cores and the terminal itself. Not to mention difficult to migrate to other midibox devices.

From a hardware standpoint though, it is the most elegant.. Clean.. two wires to each core..

and as I said.. MORE IO.. you could use half of the LCD port on the core for other duties.. AND.. being a serial terminal.. could have a lot more controls on the control surface.

I would advise against any analog signaling or anything that demands precise timing here. menu stuff is fine, but music control should be left to the dedicated hardware.

a note from systems design:  “when faced with a complex processing challenge, distribute, distribute, distribute.”

[jrp]

thanks for the info. Now at least i know that it could be done. I already notice, the more i learn about these projects, the more i understand that i´ll have to get some programming skills…

Ok, what about saving settings from the midicv? It doesn´t say anything about that in the documentation, so i guess it´s not implemented?

This is slightly off topic now, i know, but since i had the idea of sharing controlls i have come to the conclusion that it would be best to get rid of the lcd all together, since the mboxcv will have a  special job and  i´ll never use more than 2 or three setups.

If it´s realistic for me, i´ll try to find out how toi do it, once my cv is running.

My personall application will look like this: A big analog synth with 4 or 5  linear sawcore-oscillators, driven by a v/hz cv. That makes them simple and small and easy to use. No more tempcos and hi freq trimming.I want a poly mode for chords and an unisono mode. maybe also different split opotions. These settings can easily be configured on the midiboxcv. But that´s no good workflow. I guess there quite some turns and clicks to set up the box - every time.  My aim is to get rid of the lcd once the midiboxcv is configured and have two or three buttons to load different (prepared) setups.

THis would be nice in any case, also when a lcd is being used.  Just have quick access to the most often used settings.

We´ll see if i get to this, first i have to learn something about code though…

[T.K]

Only one setup is stored within the internal EEPROM. BankSticks are not supported, only SysEx dump exchange. But it could be easily added, as storage accesses are already isolated in cv_bank.inc

I think that all the imperfections in the handling make clear, that MBCV was only a quick hack I made for a friend. I don’t use the MIDIbox CV by myself - the user interface would look really different if this would be the case.

For example, I would replace the “select” button by two buttons for CV up/down. Cycling through the CV is very time consuming, I don’t really like this handling (it was made to stay compatible to the MB64/MB64E menu navigation - but there is no real reason for doing it always the same way)

Also the possibility to store multiple setups is an important point.

Another missing but useful feature is the possibility to activate an interpolation for incoming 7bit CCs (it’s like an envelope follower) to avoid steppiness and to get use of the full 12bit resolution.

Best Regards, Thorsten.

[jrp]

that MBCV was only a quick hack I made for a friend

Wow, i wouldn´t have thought that.

I know no midi cv out there with such cool functions (number of outs, different responce, curves, etc)

And i kow no midicv that is easy to use… i wouldn´t even expect it to be. Did i mention that your design even has a display?

Anyway, normaly it´s set it up once and leave it.

There are propably few people who want to switch between different setups.

One feature that might be really useful, and maybe easy to implement, would be to assing some of the cv outs as dynamic triggers.

So any cv-out could be swiched to give a short velocity dependant pulse when reciving a note. Or in another mode keep the pulse till the key is released and return to 0v after that. Then it could fire an lag circuit directly. Much easier than triggering an envelope generator with a trigger out and multiplying the envelope-cv with a cv out.

[stryd_one]

One feature that might be really useful, and maybe easy to implement

I think that idea has been mentioned before so it might be useful… It sound easy (I say that without having thought it through) you should give it a go

[T.K]

I don’t want to say that this isn’t a nice idea, and I also don’t want to say that it wouldn’t be easy to add such a feature - but I’m sure that I won’t have the time for a firmware update in the next months.

However, I’ve started a list of feature requests here:

http://www.midibox.org/dokuwiki/doku.php?id=midibox_cv

Just add your ideas

No guarantee that I will implement this - but if something else wants to contribute, just step forward - it’s open source and one of the easier understandable applications!

Best Regards, Thorsten.

[stryd_one]

Just to clarify…

you should give it a go

That was aimed at you, jrp

[jrp]

Just too explain myself, and one  from me, since i don´t want to get on anyones nerves:

I know it was aimed at me. Didn´t have a chance to reply yet.

I also know that this forum is full of fans like me who don´t have a clou of changing the code. Still these fans keep on asking can i do this or that… hoping someone replies: “yes, i´ve done it: just change this 0 to 1”

That is because uCapps is so cool. These projects are great, and the way it´s all open makes me feel like anything is possible. So i can´t resist posting.

I know this a lot from the analog forums out there, and i´m always glad to remember how it got started for me and give a newbe some hint, rather than saying go figure it out if you want to know!

Ok, this happens a lot, and i didn´t know there is a wishlist.

What i really like about this forum is how everyone is encouraged to contribute. Really.

For me the solution is easy. Takes one more vca, or easier an analog switch turning on the cv when a trigger is high. I guess the delay between the two is not too big?

That´s really the only question i have in mind. When a new key is hit, will the trigger go high while the cv is still at it´s old value?

And Thorsten, i belive it´s easy compared to your sequencer and other projects. In fact i have been reading lots of the code. Since you wrote more explanaitions than actual code, even someone like me can figure out little bits of the more general functionality of such a programm.

Still i´m suprised every time again of how much language even such a “simple” program consists. Sure some effort.  - and all going into that little chip… Fascinating!

[stryd_one]

It’s cool man, I just didn’t want TK to think I was telling him to do it

I was thinking that you could just have it send the AOUT voltage like normal, but reduced to a 1ms pulse, would that work? You could make it a 1ms pulse by calling your function after the loadSRs functions…

[Shadyman]

Not meaning to bump old topics, but what about using a Parallel Port switch? Those boxes that let you select which printer you want to print to.  :-X

[stryd_one]

Nah it won’t work… you have to initialize things and give them a steady stream of data.

As for your bumping, at least it’s obvious you’re making an effort to read the forum