John E. Finster
-
Posts
279 -
Joined
-
Last visited
-
Days Won
7
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by John E. Finster
-
-
Hey, it just hit me . Since what you want to acchieve isn´t technically the same you asked for in the initial topic (sending different CCs by pressing/depressing a button) you could try something more simple.
Now you want to send 2 CCs by pressing a button and the same 2 CCs by depressing, just with a different value. So I think something like this could work:
In the *.NGC file assign 2 events to one button with a specific range and button mode:
# SOLO Track 1EVENT_BUTTON id=1 hw_id=1 type=cc chn=1 cc=15 range=0:0 button_mode=OnOff
EVENT_BUTTON id=2 hw_id=1 type=cc chn=1 cc=47 range=3:67 button_mode=OnOff
# SOLO Track 2
EVENT_BUTTON id=3 hw_id=2 type=cc chn=1 cc=15 range=1:1 button_mode=OnOff
EVENT_BUTTON id=4 hw_id=2 type=cc chn=1 cc=47 range=3:67 button_mode=OnOff
# SOLO Track 3
EVENT_BUTTON id=5 hw_id=3 type=cc chn=1 cc=15 range=2:2 button_mode=OnOff
EVENT_BUTTON id=6 hw_id=3 type=cc chn=1 cc=47 range=3:67 button_mode=OnOff
# MUTE Track 1
EVENT_BUTTON id=7 hw_id=4 type=cc chn=1 cc=15 range=0:0 button_mode=OnOff
EVENT_BUTTON id=8 hw_id=4 type=cc chn=1 cc=47 range=2:66 button_mode=OnOff
# MUTE Track 2
EVENT_BUTTON id=9 hw_id=5 type=cc chn=1 cc=15 range=1:1 button_mode=OnOff
EVENT_BUTTON id=10 hw_id=5 type=cc chn=1 cc=47 range=2:66 button_mode=OnOff
# MUTE Track 3
EVENT_BUTTON id=11 hw_id=6 type=cc chn=1 cc=15 range=2:2 button_mode=OnOff
EVENT_BUTTON id=12 hw_id=6 type=cc chn=1 cc=47 range=2:66 button_mode=OnOff
With that button mode and range the button (solo track 1) sends CC15 0 + CC47 67 when pressed and CC15 0 + CC47 3 when depressed.
If this works you wouldn´t need a *.NGR script and you could assign all the button within the *.NGC file.
I can´t guarantee for that though. Like I said, I won´t be home till next week to test this for myself.
my regards
-
Hi,
you can create as many sections in the *.NGR as you like. Here are some examples for the solo/mute/rec buttons of track 1
# SOLOif ^section == 1if BUTTON:1 == 1send CC USB1 1 15 0send CC USB1 1 47 67endifif BUTTON:1 == 0send CC USB1 1 15 0send CC USB1 1 47 3endifendif# MUTEif ^section == 2if BUTTON:2 == 1send CC USB1 1 15 0send CC USB1 1 47 66endifif BUTTON:2 == 0send CC USB1 1 15 0send CC USB1 1 47 2endifendif# RECif ^section == 3if BUTTON:3 == 1send CC USB1 1 15 0send CC USB1 1 47 69endifif BUTTON:3 == 0send CC USB1 1 15 0send CC USB1 1 47 5endifendifThe according BUTTON events in the *.NGC file would be:
# SOLOEVENT_BUTTON id=1 type=meta meta=RunSection:1 range=0:1
# MUTE
EVENT_BUTTON id=2 type=meta meta=RunSection:2 range=0:1
# REC
EVENT_BUTTON id=3 type=meta meta=RunSection:3 range=0:1
Of course you have to keep track of all the button ids and the according section numbers.
my regards
-
Hallo und willkommen,
wollen wir mal schauen....
8x8 Matrix --> da sind DIO_Matrix Module besser, die haben bereits 2 DIN und 2 DOUT Register für 2 8x8 Matrizen
128 Dehregler --> Endlosregler? Wenn ja, dann brauchst Du 8 DINx4 Module (1 DINx4 = 16 Endlosregler)
--> Potis ? Dann brauchst Du 2 AINSER64 Module, da Potis analog sind.
Fader --> Für 8 Fader brauchst Du ein AINSER8 Modul, bzw, für mehr dann das AINSER64 Modul.
--> Falls es Motorfader sein sollen, dann brauchst Du für 8 Motorfader ein MF_NG Modul
XY Controller --> kann ich nichts zu sagen, habe ich noch nie benutzt.
Ansonsten natürlich ein LPC17 Modul, wobei Du das LPCXPRESSO Board, das auf das Modul draufkommt, nicht bei SmashTV bekommst.
SD Karte brauchst Du natürlich auch, einen passenden Anschluss kannst DU Dir einfach selbst basteln.
Liebe Grüße und viel Spaß :happy:
John
-
Unfortunatly I´m not able to test this atm. I´m far away from home (and from my midiboxes :bye: ) for a few days. Next week I will be able to test this.
I suggest you try and put something like this in the *.NGR:
if ^section == 1if BUTTON:1 == 1send CC USB1 1 15 0send CC USB1 1 47 67endifif BUTTON:1 == 0send CC USB1 1 15 0send CC USB1 1 47 3endifendifThis is for the Solo on Track 1. For the other tracks the cc15 value has to be changed from 0-7.
-
Ok, I found my old notes from my "Motormix Studies" with cubase I did a few years ago and I think I can dare to take a shot at this:
For every button there has to be sent 2 CCs, the first one selects the channel and the second one sets the function (like solo, mute,.....).
Now, if I remember correctly, the 2 CCs have to be sent twice (so 4 events in total) with different values to set a function.
CC VALUEFader Touch:
15 0(0-7)
47 64
15 0(0-7)
47 00
Select:
15 0(0-7)
47 65
15 0(0-7)
47 01
Mute:
15 0(0-7)
47 66
15 0(0-7)
47 02
Solo:
15 0(0-7)
47 67
15 0(0-7)
47 03
Multi:
15 0(0-7)
47 68
15 0(0-7)
47 04
Record:
15 0(0-7)
47 69
15 0(0-7)
47 05
Regarding the PING, I think you can ignore it for now. The Mackie Protocol too has some kind of PING thingie integrated but I didn´t have any trouble ignoring it (at least with Reaper and Ableton).
EDIT: Sorry, I got some messed up notes lying here :rofl: . I changed the events again...
-
With what DAW are you trying to use the motormix emulation?
I remember that cubase sends different midi events to the motormix than described in the motormix manual.
-
Hi Reggie,
I didn´t follow the developement of the stm32f4 discovery closely, but I don´t think it is quite ready yet to be integrated into the midibox hardware platform and probably won´t be until some time next year. So If you want to start now and don´t want to wait a year, you could focus on the current LPC17 core. As far as I see it, every idea you have about your controller can be easily realised by the available technology right now.
I suggest you have a look into the MB_NG firmware here, which is the most flexibel and powerful one right now.
Also have a look at all the available hardware modules. I think you misunderstood the concept behind them. First you need a core module (like the LPC17) that is able to run the MIOS32 system and the firmware you like. If you want to use hardware elements like buttons/encoders/leds/.... you have to connect all that to the core via another hardware module, the core itself doesn´t provide (many) pins for direct connections and neither will the new stm32f4 core.
So you need additional modules for your control surface elements:
encoders, buttons ----> DIN module
faders, pots ----> AIN or AINSER module
motorfader ----> MF_NG module
leds ----> DOUT module
etc........
Have fun!
my regards
-
Hi,
I´m not able to test it for myself atm, but maybe this could do it. I´m using similar methods for my own box.
You need a *.NGR script to do that:
in the *.NGC:
EVENT_BUTTON id=1 type=meta meta=RunSection:1 range=0:1and in the *.NGR:
if ^section == 1if BUTTON:1 == 1send CC USB1 1 15 0endifif BUTTON:1 == 0send CC USB1 1 47 67endifendifMaybe this will do the trick.
my regards
EDIT: Just tested it and it works! The button sends CC15 v0 when pressing and CC47 v67 when depressing.
-
Hi KUI,
a schematic for one shift register can be found here. You could also use a regular DOUT module. Actually I recommend using a full DOUT module (4 shift registers). Because of a problem with my ssd1306 displays I was forced to skip every second shift register pin, so I have only 4 displays per shift register.
I had some more trouble (well, still having...) with the displays. If you are interested, you can read about it in I was able to solve some of the problems myself, but there is still one open issue. I hope this can be resolved soon.
my regards
-
MB_NG V1.027
Event Pool Number of Items: 201
Event Pool Allocation: 7329 of 24576 bytes (29%)
Every label is stored in the *.NGL file. Only a few are defined in the *.NGC (direct ´LCD "" ´ messages plus some sysex messages).
That´s without any banks for now. I´m planing on using at least one other bank and probably lots of conditional events in the future.
-
Hi, to make use of the new MIOS32 you have to get a new LPC17 core module.
my regards
-
-
I got them on ebay from a chinese dealer for ~ 9$ a piece plus gratis shipment.
my regards
-
Hi, Thanks for the compliment.
Well, regarding the time... With all the "normal" everyday background (familiy, job,...), once I had all the parts, it took me about 4 weeks to put it together, another 2 months to fight bugs and mistakes I built in (I was a little too eager and impatient at the start...) and maybe another 2 months to create the necessary scripts (.ngc, .ngl and .ngr) and fonts/icons to get it to work like that.
Of course a lot more time went into the research of the Midibox concept, hardware and software knowledge and figuring out what I wanted in the first place. I´ve been around here for the last 6 years, that´s when I started to build my first cardboard midiboxes. I had to get a break when my lovely daughter was born to take care of more important issues, but from time to time I was sneaking away from that to continue my Midibox research.
Of course without that much in the background, on top of mine I was a college student until 3 months ago, I would say it doesn´t take more than 6 months to research the Theory and to build some simple boxes to experiment.
I think the hardest part in all this is to get started....
my regards
-
Hi,
I´d like to present my newest built. Today I finished a preliminary *.NGC file to get it to work like I want it to, so I´m officially announcing it finished :sorcerer: .
This is supposed to act as a Mackie Control Clone, but I tried to keep the designation of the design as wide open as possible to use it for other purposes as well. There are still some issues I have to work out (mostly related to the SSD1306 displays), but as for now it´s usable as it is.
Here you go:
It features:
9 Penny&Giles motorfaders (8 track faders + 1 master fader)
14 Encoders
2 jog dials with different caps (one with pimples and one with a finger hole)
70 multi-purpose buttons
18 SSD1306 displays
customised fonts and icons
Inside are:
1 LPC17 core
2 MF_NG modules
1 DOUT module
4 DIN modules
This Midibox is powered by a simple Wall adapter with 14V 2A.
I didn´t print any labels onto the front panel. There are some color-coded buttons for the most needed functions (track select + shift and modifier buttons).
The purpose of all other buttons can be indicated by a label printed on one of the SSD1306 displays. This ensures that I can change the function (and the apropriate label) of almost every button without worrying about any labels/indication leds/front panel positions.
The frontpanel is made by Schaeffer, the case is made out of beech tree.
I will provide a more detailed documentation in the wiki soon.
Many thanks to TK and to the very helpful community, without which I would have never come this far.
my regards
-
2
-
-
Hi,
do you want to connect this USB-powered keyboard controller to the MIDIO128 directly, so that midi data can go from the keyboard to the MIDIO128? In this case, you have to use the midi in/out connections of the core, this can not be achieved by an USB connection.
Also the USB plug of the MIDIO128 does not deliver currency, when it is powered by an external psu.
How would your setup look like?
1. MIDIO128 -> PC/Mac and keyboard -> PC/Mac
for this scenario I would recommend an active usb hub, where you can connect both the MIDIO128 and the USB-powered keyboard controller. But here no direct connection is possible, everything has to go through the computer.
2. Keyboard -> MIDIO128 -> PC/Mac
the keyboard here has to be connected via midi in/out, the USB connection can not be shared.
3. Keyboard -> MIDIO128 -> Synths/other Midi gear
the keyboard here also has to be connected via midi in/out, the USB plug does not deliver currency.
It is possible to build in a seperate plug for 5V that matches the USB cabel. It could be connected to an open 5V line on the inside. But it would not be possible to send/receive midi data over the usb connection anymore.
-
Yeah, it´s kinda interesting. I had to look twice a the midi input monitor of Mios Studio to get it :happy: .
If you choose Motormix emulation and look at the direct output of the MF module in Mios Studio you can see two CCs instead of one when you move a fader. So that´s how 14bit resolution is generated. (CC a) x (CC b) = 128 x 128 = 16384 = 14bit!
With the regular pitchbend mode or the mackie/logic emulation mode there would only be a 10bit resolution available.
-
Am i wrong thinking MF_NG has to operate in Motormix emulation anyway...?
If you want to use a mackie/logic emulation, you´re right. For other applications you could use other modes.
I believe it has something to do with the resolution of the faders. The Motormix mode provides 14bit fader resolution.
my regards
-
Ahh, I see light.... :w00t: .
(sorry, I had to put my grammy into a hospital last night..........again.......... so I´m a bit exhausted. Ok, back to topic!)
I don´t know about the command8, but the others, HUI and Motormix, are documented.
With HUI you might be able to set up....:
- vu-meters -> transported by a key aftertouch event which could be recognized by a MB_NG and translated into a led or lcd event.
- encoders, switches, led-rings -> they´re all continous controller events which can be assigned by MB_NG
- 2x40 lcd display -> for displaying fx parameters (like HUI), sent within a sysex stream which could also be recognized by MB_NG and displayed on a lcd.
With Motormix you might be able to set up....:
- 2x40 lcd display -> track names, also sent within a sysex stream.
- encoders, switches, led-rings -> like HUI
You could combine both protocols into one "midibox bar" to attach to your fader boxes. HUI could give you metering and Motormix could give you LCDs with track names,...
I recommend you monitor the midi output of all 3 midi protocols (from command8, too) to see, what and how controller information is transported (this can differ from daw to daw). You already know Midiox, which is an excellent tool for that. Just connect the midi out of protools midi protocols to midiox (via LoopBe or other virtual midi cable) and record the output. If everything is alright you should able to see note/controller/aftertouch/sysex commands from protools, which we can interpret and maybe emulate.
A word of caution to this tale...(my kid loves that disney Hercules movie...)
1. Everything I wrote here is considered hypothetical. I got similar stuff to work with my boxes, but of course I can not guarantee that any of this will work in your case. Especially, since I don´t know Protools and its potentials.
2. Since you´re focused on meters I´d like to add another comment. Midi-driven meters are never that accurate as audio-driven meters or those you see on the screen of your laptop/pc/mac...whatever. They can be (rough) indicators of what is going on, the whole meter length is roughly divided into 11-13 sections and they have a noticeable latency. If you´re looking for professional and precise meters, a midicontroller is might not be the solution.
Then again, I am really tired right now, so if any of what I just wrote doesn´t make any sense, please bear with me :ahappy: .
my regardsP.S.: If you can give me some time, I could test the metering feature of the HUI protocol within Reaper (IF it supports metering) and report back.
-
Hi,
I´d like to give another update on my situation.
1. I installed a heatsink onto the 7805 and this seems to fix the problem with the displays going crazy, I didn´t have a dropout since then.
Thanks again, Duggle, for the tip!
2. I was also able to fix the problem with the cut off characters when using the mcu host message and the ^txt56 command.
Instead of using the ^cursor command I defined a seperate RECEIVER event for every occuring cursor position inside the sysex stream from the mackie protocol. For Reaper there are 16 ( 2 for every track -> 1. and 2. line ) and for Ableton there are 2 ( 1. and 2. line ). Every receiver became it´s own lcd position.
3. I´m still working on the problem with missing pixels/characters.
For the startup of my box I set up an *.NGR script, that first locks the faders, then performs 5 lcd updates and then unlocks the faders again.
That works on a startup.
I tried using a script with lcd update commands for other functions that require screen changes, but unfortunately the fadermotors seems to react on a meta event and "twitch" whenever a meta event is executed. This can cause small, but sometimes very annoying parameter jumps.
This approach doesn´t seem to work as a permanent workaround for the situation.
That would be it for now. I will report back if anything new comes up.
my regards
-
I believe so, yes, using the Mackie Protocol from Klinke. But I´m not completely there yet.
I was able to display the meters on my ssd1306 displays and generally they work, but there are a few things I have to work out before I could say, they´re completely usable.
The problem seems to lie inside the Mackie Plugin from Klinke. Normally (with the MCU) the meters are activated by a sysex string followed by a stream of Note and Aftertouch events to transport the meter values. I was able to reproduce the stream, so my meters are "twitching", but I´m still missing the proper sysex string. Same goes for the MTC display, btw.
As I said, I believe it´s doable, but there has to go a bit more work into it.
-
A possible compromise in this case could be combining different protocols.
I don´t have Protools, but I believe, it also supports Mackie Protocol. It might be possible to attach a (MB_NG-) meter bridge to your faders which is driven with Mackie Protocol. There might be issues to work out if you want to sync both "elements" (e.g. fader bank switching,...). But as said, I don´t know Protools and its possibilities on that area. I guess you will have to set up a lot triggers and translations e.g. with midiox and others, but so far as I understood, you are already doing this to get your faders going.
How can your Fader boxes be connected to your daw?
What kind of protocol are you using now? Are there other (midi based) protocols inside Protools you could exploit?
Novski is certainly right about Avid, they´re a pretty uncommunicative bunch when it comes to their products. The only possibility one has to get behind the curtains is to reverse engineer their gear. But even then I believe there are technologies involved, which can´t be emulated with a Midibox Controller.
my regards
-
Hi,
you would need some documentation for these surfaces which contain the sysex implementaion (assuming the meters are transported via sysex). Once you have this, you can set up a receiver event inside MB_NG that can get the sysex events and "translate" them into led or lcd events. I know, this is possible for the Mackie Protocol.
I don´t know if there´s a public "implementation chart" available for control 24 though, you might need to reverse engineer this, if you can get your hand on one of those surfaces.
Here you can find a conversation on the Reaper forum regarding this topic. I don´t know, how far they have come, but it might be worth a look.
my regards
-
Hi,
I can´t tell if it is possible from inside the midibox to assign special functions to buttons, but there is a small app an the midibox_64 site here wherein you can do that. But it is Windows only...
my regards
FL Studio MIDI Controller
in Deutsch
Posted · Edited by John E. Finster
Hallo nochmal,
Ich möchte aber nochmal hier nachhaken. Dass dies eine Schularbeit ist, stand nicht in deiner PM, daher würde mich das schon interessieren.
Wie lange hast Du für diese Schularbeit Zeit? Welche Schule und welche Stufe (Klasse)? Hast Du Dir überlegt, wie das finanziert werden kann? Hast Du Lehrer/Mitschüler, die Dir helfen können?
Sorry für die vielen Fragen, aber ich denke, das sollte mal geklärt werden.
Gruß