midibox deck project (rgb leds, buttons, knobs)

[Guest julienb]

hi !

I'd like to build a deck:

- around 100 knobs,

- around 80 buttons,

- around 50 rgb leds

I'd like to know more about some concepts/questions

cascaded core

with my project, I'd probably need more than 1 core.

I read about cascading 3 cores and midi feedback problem.. but up to 2, is there problems like that? is it efficient?

how goes the codes with more than 1 core? will I have to specialize cores? (one for input, the other for output)

rgb leds

does it exist C++ classes to handle rgb leds? I'm sure I could tweak C++ classes for monochromatic led to use it with rgb, but I guess there are a lot of people who already did it (and very better than I could produce!)

scalability

does my project seem fit with the midiBox framework ?

I mean with these high numbers of i/o..

to begin

where could I begin? should I alter a midi128 projects ? should I start from scratch?

any advices would be appareciated !!!

cheers,

julienb

[mr_DK]

Hi julienb,

I'm not such a specialist myself but I try to help you were I can:

100 Buttons, no problem you can handle 128 buttons with one core (using 4 DIN modules)

100 knobs, are it encoders or analog pots? Because on a standard core you can only connect 64 encoder (when they don't have a push function which would need another input off course) So you need already 2 cores to handle the 100 encoders. Also with pots (AIN modules) you can only connect 64 to one core.

50 rgb LEDS, this will probably be the "hard" part, as far as I know you have two options, you can use DOUT modules which gives you the standard 8 color options, or you must connect them to an AOUT module to create all RGB colours. (It's just logical thinking, I'm not sure about this, someone please correct me if I'm wrong ;)) There are some assembly drivers on the forum, but none in C...

There are some more discussions on the forum which handled RGB leds or duocoulored leds:

http://www.midibox.org/forum/index.php/topic,10476.msg79410.html#msg79410

http://www.midibox.org/forum/index.php/topic,11541.0.html

http://www.midibox.org/forum/index.php/topic,12748.0.html

Here you can read more about connecting multiple cores: (I guess the feedback trouble is fixed)

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

I guess you could try the midi128 or the MB64 but off course you will have to make some adaptations.

I hope this was a bit helpfull...

Regards

Hans

[Guest julienb]

Hi Mr_DK,

and thanks !!

ok for buttons.

these will be pots and not encoders. so I'll need 2 cores, btw.

for the led part, I already worked on it, and I can understand what it is under the surface. but I need to go further in midibox framework to understand how it goes !

I'll try to make a functionnal schema in order to understand... I'll post asap.

for the code... where should I "put"/upload them? in the two cores? this is the part I can't figure out..

[stryd_one]

with my project, I'd probably need more than 1 core.

99 times out of 100, New guys who think they need a squillion knobs/buttons/etc, don't really... Why do you need so many?

I read about cascading 3 cores and midi feedback problem.. but up to 2, is there problems like that?

Cascading 3 cores should not be problematic any more so than 2.

will I have to specialize cores?

Have a look at MB-Link

does it exist C++ classes to handle rgb leds?

No, they're in PIC ASM. You could maybe write some in C, but that might be too slow. Best to write your app in C, and use the existing drivers.

does my project seem fit with the midiBox framework ?

I mean with these high numbers of i/o..

Yes :) But you can probably use a lot less (again, thanks to the flexibility of the platform).... It depends on your use case... We'll see...

where could I begin? should I alter a midi128 projects ? should I start from scratch?

It depends on your use case... We'll see...

Tell us more :)

[Guest julienb]

julienb> I answer in the text, in red color.

99 times out of 100, New guys who think they need a squillion knobs/buttons/etc, don't really... Why do you need so many?

julienb> I could describe more but I only can do it fast: 3 sends for each of 8 tracks + 3 for each tracks + 6 for each sends section + around 12 for master section... + 1 volume + several other for other functions... the limit is very fastly reached.

I already own a BCR2000 ... cool, but in live performance I HATE to change the preset etc... I want to have all my functions available at the same time.

Cascading 3 cores should not be problematic any more so than 2.

julienb> cool.

indeed, I read about that. I just wanted to be sure.

Have a look at MB-Link

No, they're in PIC ASM. You could maybe write some in C, but that might be too slow. Best to write your app in C, and use the existing drivers.

julienb> no prob (except that I don't understand ASM and I don't want to learn it. As you wrote, if I can use existing drivers, it would be great!

Yes :) But you can probably use a lot less (again, thanks to the flexibility of the platform).... It depends on your use case... We'll see...

julienb> ok!

It depends on your use case... We'll see...

Tell us more :)

[stryd_one]

Strange thing to do.. why

[color=red][/color]

instead of copy/pasting the

[quote name=stryd_one link=topic=13002.msg110747#msg110747 date=1234802342]
[/quote]

Or just using the buttons....? anyway.... :)

Usually, the idea behind reducing component count (and therefore size, cost, complexity, etc) is to use a banking scheme... So like, you'd have your 8 tracks with three knobs and 3 buttons (for example) on each, and switch between the banks to get at track 9-16, 17-24, etc. The reasons are pretty obvious: you only have two hands, your range of vision is only big enough for a small area, moving your hand from control, to bank-switching-button, and back to a control, is faster than moving your hand from control to another distant control... etc etc...

Having used both big desks and small ones with switching capabilities, I can tell you that in a live performance, even if you ignore the massive difficulty in moving a huge controller to your gig, and the fact that most venues don't allow space for such things at their consoles, you'll still prefer the smaller switching controller, for the reasons mentioned above.

If you're finding the BCR's bank switching cumbersome, I understand - but that doesn't mean that the concept of control switching is flawed, it just means that the bcr's particular implementation does not suit your style of performance.

Perhaps, rather than making something impractically large and cumbersome, you should consider taking advantage of the prime reason for DIY - custom design.

For example... how ofter do you change the sends on more than one channel at the same time? Probably never... So, just have ONE set of send levels knobs, and have them send for whichever track you have selected. Another: How ofter do you change the master levels during a set (should be never!! or your PA guys will rightly think you're a pain in the ass!) in this case, you can have a 'page' setup, for the master section, which takes up the whole controller.

these are just examples off the top of my head... What would or would not work, really depends on how you use it, and only you know that.

Look, there is a reason why most desks have send levels on every channel. But it's not practicality. It's nostalgia. Back in the day when these things were analog, there was no other option really. But now you have a lot more flexibility in your design. Make use of it... but to do so, you need to think outside of the box someone else created (the normal mixer layout) and start thinking about what you really need. don't take a step backwards into design world from 50 years ago, step in the direction you really want to go.

[Guest julienb]

it is like the guy who asks: " hi I want this car", and the other guy who answers to him: " no, this one is better for you"  :)

Really, I don't want to have a headeache with all of this.

I really need this feature, I already think and think more, test banks, test 2 BCR together etc etc.

I just hope I could do that with midibox stuff.. and it seems to be the case :)

[Guest julienb]

[mr_DK]

these will be pots and not encoders. so I'll need 2 cores, btw.

Don't forget that with pots you can't use bidirectional communication with your PC, the PC is not capable of changing the value of a pot (unless it's motorized) That's why encoders come in handy. I think youre trying to create a digital console? You might have a look at the MBLC project which is an emulation of a mackie control. I'm building one of these myself but also with some more encoders because one is really like not much. I know what stryd_one is trying to say, don't make it to big from the first day, just start with like 4 encoders (or pots) and try if you can get them programmed and at some more time by time. (the way I usually work)

[Guest julienb]

mr_DK,

I want pots, not encoders.

digital console? mackie emulation?

I just want to make my controller to control my live set on Ableton Live 8 + max for live (as soon as it will be released :) )

[stryd_one]

it is like the guy who asks: " hi I want this car", and the other guy who answers to him: " no, this one is better for you"  :)

No, not at all. perhaps you should re-read my posts. This is more like:

Car amateur says: I want this ferarri to drive my 8 kids to school

Experienced mechanic says: Maybe you'd be better off with this minivan, but I need to know more about your situation to give you good advice.

Clearly from your reply to me and mr_DK (who is probably right, by the way, you really would be better off with encoders, especially with the software you want to use) you don't want any helpful advice, so I will wish you luck!

[stryd_one]

I know what stryd_one is trying to say, don't make it to big from the first day, just start with like 4 encoders (or pots) and try if you can get them programmed and at some more time by time. (the way I usually work)

Well that works too, but what I'm trying to say is, there might be a better way than making a gigantic controller, depending on use case.

[Guest julienb]

please guys..

I understand that you just want to advice me, warn me and I'm sure in 99,98% of case, you'd be right.

But I really came here after thinking/testing/performing etc and my thoughts hit this step: I need this kind of gear.

probably +-10 buttons/knobs etc... but this kind of "big" gear.

So, as I'm sure your experiencies/knowledge is very big, could you only focus on steps to follow to reach my goal?

I'm sure you can :)

[stryd_one]

could you only focus on steps to follow to reach my goal?

I'm sure you can :)

That is precisely what I've been doing. What else do you want?

Edit: Oh btw:

99 times out of 100, New guys who think they need a squillion knobs/buttons/etc, don't really... Why do you need so many?

What do you think every one of them says?

But I really came here after thinking/testing/performing etc and my thoughts hit this step: I need this kind of gear.

And ahh... If you were serious about this message:

digital console? mackie emulation?

I just want to make my controller to control my live set on Ableton Live 8 + max for live

Then it's clear you missed a few things.

[Guest julienb]

That is precisely what I've been doing. What else do you want?

I'd need info about where the code goes.

I mean, I'll "specialize" each core in my case, if I understood correctly.

So I'll need 2 differents code (=applications, in midibox language) for each core .. am I right?

People talk about "driver"

they mean "MIOS" ? or applications layer ?

I'm confused about that because the wiki is very precise, but people not ;)

I watched C classes that we can use.

I'd need to know more about applications.

I'd like to merge some conf with rgb leds, pots and buttons in order to figure out how all can go

thanks a lot

[mr_DK]

People talk about "driver"

they mean "MIOS" ? or applications layer ?

A driver is an implemented piece of code which is used by MIOS to use special functions like GLCDs or other special components.

I'm confused about that because the wiki is very precise, but people not ;)

To be honest, people here are really precise, they know exactly what the whole MidiBox project is about. Only for you it's very difficult to help because you're new here and you want to create a huge project which has no design tutorials online and I think you don't really know what you want for yourself. Always remember that people like stryd_one and TK are the big V8 engines behind this whole project, they know every detail from hardware to software! The only thing you need to do more in my opinion (it's just advice, do with it whatever you want) is to read and get to know what you want to build:

What I think is that you want to build a "controller" for Ableton which is a DAW. There are already many premade mixing consoles on the market which do these things (some things you should really know when you want to work with MIDI to control audio software)

Have a look at the following website:

http://www.mackie.com/products/mcupro/index.html

http://www.euphonix.com

This is the famous Mackie control about which I was talking, it looks like your Behringer controller but some more control functions. It's this one that is emulated with the Midibox LC. I guess you want to end up building a console like a Euphonix or something which is possible when you add some more encoders to the project. But the MBLC is a good start to get to know the midibox system and afterwards you can expand like your wishes are.

Clearly from your reply to me and mr_DK (who is probably right, by the way, you really would be better off with encoders, especially with the software you want to use) you don't want any helpful advice, so I will wish you luck!

This is the last time I will talk about these damn pots, always remember when you use pots and not encoders, when you open a file in ableton, your pots just won't adjust to the value your current FX preset has!! That's why encoders are so important, when you open a preset like for EQing in your ableton, I hope you wish that the console takes over the same values? Well, with pots it simply can't... They stay as they are and the computer cannot change the values.

you don't want any helpful advice, so I will wish you luck!

I guess stryd_one is right, you ask for help but you already made your mind up about what you want.

[Guest julienb]

probably I have to tell it in another language:

je ne veux pas utiliser d'encoder mais des potentiomètres. c'est un choix. c'est le mien. il est peut être mauvais, mais c'est le mien et j'ai déjà réfléchis à tout cela.

more seriously, mr_DK. relax. I don't want to make a big post with words like that.

it is only a technical post and yes: I already have a lot of thoughts about all of that, and yes my choices remain these, cause it is only what I need... and I'm not the only one to have need like that (noofny,robert henke, and I have other friend that made their gear..)

but respect my choices even if it is hard to twist your mind to.

I'm sure you understand that.

[mr_DK]

Sure I respect your choices,

If you're sure what you need then go for it!

good luck

[Guest julienb]

Sure I respect your choices,

If you're sure what you need then go for it!

good luck

thanks mr_DK

I just hope you'll help me, cause I'm sure your help would be precious!

cheers

[stryd_one]

So I'll need 2 differents code (=applications, in midibox language) for each core .. am I right?

Yes. It's an application in any language really, it's executable code that needs an OS, just like firefox is an application on windows if you like :)

People talk about "driver"

they mean "MIOS" ? or applications layer ?

They are optionally included in your application code. Think of them as libraries which provide an API to perform your required functions.

I'm confused about that because the wiki is very precise, but people not ;)

People wrote the wiki. I wrote big chunks of it, at great effort to myself, as did the many other people who have volunteered their time to make it what it is. If you want the wiki to improve, perhaps you should join the very small group of time-limited volunteers who are copying the current pages to a new layout which is easier to understand and update. Otherwise perhaps you could be satisfied with what has been provided to you.

Might I suggest you show a little more respect if you want me to help you out. Please refer to my signature, click the troubleshooting link. #4 is for you.

I'd need to know more about applications.

Like?

it is only a technical post and yes: I already have a lot of thoughts about all of that, and yes my choices remain these, cause it is only what I need... and I'm not the only one to have need like that (noofny,robert henke, and I have other friend that made their gear..)

but respect my choices even if it is hard to twist your mind to.

You keep making these implications that your choices are not being respected and that is putting words into our mouths which is disrespectful in itself. We aren't disrespecting your choices, we don't know wtf they are! That's why I asked you!

I was restraining myself earlier, but I'm over it now, so I'll post the whole thing:

Car amateur says: I want this ferarri to drive my 8 kids to school

Experienced mechanic says: Maybe you'd be better off with this minivan, but I need to know more about your situation to give you good advice.

Car Amateur says: FUCK YOU ASSHOLE RESPECT MY DECISION I WANT A FERRARI FUCK YOU GIMME MY FERRARI!!!!

(You're a little more passive-aggressive in your response, but the gist of it is the same. I know that a shit coated in honey is still a shit.)

Now, it may very well be, that you have 8 kids, who all start school at 0830, and they are all at different schools in different areas, and so you need to carry one of them at a time, and you need to drop one off and pick up the next one from home to take them to school, at super speed. In which case, you really do need a ferarri. Or maybe a gyrocopter. And if I was the experienced mechanic and you told me about the 8 schools and your need to drive at 300km/h, I would have said "you're right, you really do need a ferrari, let me show you this latest 2010 model we have on show...."

Switching from the metaphor to reality, like the pots... Now, encoders are generally a much better way to go, for reasons such as those DK has outlined. Now, sometimes, there are actual reasons to use pots instead. Now, to mirror the metaphor, the conversation we have had is like:

You: I want pots

Me: perhaps you'd prefer encoders, I don't know.... what's your plan?

You: RESPECT MY AUTHORITAH! GIVE ME INFO ABOUT POTS!

Now, if you said :

You: I know what you mean...  But I need pots because I am vision impaired and I want to know when I have a certain value.

I would have said:

Me: Aha you definitely want pots! You will need to implement a soft takeover function, but that is totally doable.

Etc etc.

I'm not disrespecting your choice, how could I, I don't know what it is, because you refuse to tell us. All I can do is guess, and advise you based on that - and that's exactly what I'm doing. This is a GIGO situation. You get to fix up the input if you want to fix up the output. Don't blame the processor.

This "hard to twist your mind to" thing is crap. That's like telling me to go to Townsville but not telling me where it is.

Seriously, I have answered every question you've asked. II you're still unsatisfied.... Hell, I couldn't give a damn. I've spent way too much time on this, and so have you. I've answered all your technical questions but I've spent so much time trying to get you to show a little bit of respect I don't really feel inclined to respond further, technical or otherwise. If you wanna be rude, you can do it all by yourself.

The stupid thing about it is that you've spent more time bitching about being asked for information, than it would take you to just give the information.

[Guest julienb]

no comment.

not time for that.

thanks for the big part of infos.

I'll try to figure out this amazing framework

[stryd_one]

No comment? You just DID comment. You get more rude every time you post.

no comment.

not time for that.

thanks for the big part of infos.

I'll try to figure out this amazing framework

What was I saying about shit coated in honey?

What a surprise, the reply to this... more shit coated in honey, more accusatory tones, more "woe is me", and the same lack of a straight answer. And a thread lock. I *could* just post again; being a mod, thread locks don't effect me... but why draw the attention of this troll?

[Guest julienb]

I just would like to get help

and I got that...

I'm disappointed  :-[ :-[ :-[

bouhhh.

but relax.

we're all passionned by midi, gear, box, code etc

let's be friends :)

I lock this topic because it begins to become unuseful for the others.