Melonenmonster
-
Posts
25 -
Joined
-
Last visited
Never
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by Melonenmonster
-
-
will we have access to the protocol that MFL uses, so we can choose not to use it and still gain control over live? i'm not expecting a "yes" to this answer, but i figured i'd ask anyway.
MfL will be the only offical, legal, reliable and supported way to do it.
i don't see why an additional control layer is necessary when i've accomplished all kinds of control over live without it. in fact, i've managed to do pretty much everything i wanted to.You are right, to provide Live control we tried to use what we have as much as possible. The layer on which the LiveAPI-hack is build is actually the software used to implement the support of all the different hardware controllers. We extended this layer by new functions (like note access) and put software into it which would allow us to keep the Max interface to it as stable as possible when the internal data model changes. Also we have to manage the relation to Max objects, send notifications etc.
my only concern with it is what you stated, that it can change with versions.Some parts of the layer which you use via the LiveAPI have significantly changed with Live 8, others not. So, indeed using MfL will be more reliable.
but it sounds like you have something pretty much solidified, and with MIOS32 supporting OSC, we could have a nice tight integration with live without the need for an additional control layer. i am very interested in what MFL has to offer, and i'd like to be able to control these step sequencers in the way i'm able to control any other kind of device on a track. if you're interested in knowing how this particular diy builder wants to take control over live, i started a thread a while ago that completely describes the controller i'm planning: http://www.midibox.org/forum/index.php/topic,12636.0.html. i've tested pretty much every aspect of this controller's description, and i think it's all currently possible.Well, a nice and quite original design. Not one of the Mackie HUI lookalikes you see each day.
does the akai controller require MFL to work?
No, there's the usual control script for it.
if not, do we get access to the same thing it uses?
I don't know exactly what the communication is between Live and the APC. AKAI says its proprietary, so I guess the APC script can be used only for the APC.
is liveapi going to go away with live 8?
The software layer still exists, although it has changed. I cannot say if the hack will keep working.
with MFL, how will control over master sections (such as transport) work? to my understanding, max is used as a device on a track, and i'd assume it's there to control track-related items. i can see how getting at info on tracks could be made easier, but what about controlling live in general?
Using the live.path object in any Max device, you can "goto" the Live set and from there to any track or its content like clips or devices, and start doing something with the objects there. You can also go to the loaded controller script and hook up your own functions, like Jan Buchholz did in the video to use the APC to control the notes in a midi clip.
Yours,
Ralf
-
maybe i've jumped the gun a bit. at least, i'll take your word for it that you're not just here to market MFL.
i have a few questions: ...
Ultra, thank you for your reply. I'll need a little time to prepare some material for the answers
and also to look at yours.
Ralf
-
Hi Ralf, this sounds very promising to me.
When I read all the news about the new Akai hardware and MaxfLive I did not think that the protocol between APC40 and Live would be available for general usage (maybe this is not what you suggest, maybe you mean an intermediate API which only works with MaxforLive).
Max for Live provides Max objects which allow to control Live, opening a significant part of the internal APIs, abstracted to the user level, where a set is a set, a clip is a clip, and a device parameter is a ... you name it.
In any case, I am sure many builders here around would be heavily interested in any kind of API for Live, and I am happy to read that there is some open communication from ABLETON "Headquarters" to a DYI-project like the Midibox.I'm speaking here as a private person, but I decided to be not only melonenmonster this time, because you should know that we are thinking about you when we do such things and when we have to decide where to put our efforts.
Ralf
-
do the max for live plugins have their own ram adressing? i plan on recording many tracks to long buffers for processing inside the max plugins. and am worried about hitting the ableton's maximum ram allowance.
They run inside of the 32 bit Live process and thus are limited to the 4 GB RAM limit (3GB on Windows). I cannot say anything about 64 bit at the moment. But I guess you could record into files using Max and then stream/process them, if that would help. At least that's what Live is doing. Another possibility is to start new child processes from Max and communicate with them, using TCP/IP for example. Each of them could hold their own 4GB then. I don't know how much physical RAM you have or need, though.
-
ralf,
i'm struggling to understand this post for a couple of reasons. the first is that liveapi does exist. in fact, i've been working on a system that allows any midibox user access to live that go beyond the new akai controller and the monodeck II. i'm even able to access track, clip, device, and device parameter names and put them on the midibox, after automapping the midibox to each control. feedback on clips is an easy one. so the system exists, it's just that we weren't really told about it and how to use it. which leads to the next reason i'm confused.
Ultra, as you know, Ableton was aware of the LiveAPI, and although it was a hack into the inner parts of Live and thus a violation of the license, ableton decided to not only tolerate this attempt to get an API to control Live, but welcomed it. The reason is that we knew a demand for such an API exists, and people were putting thier efforts into it, but we also appreciated their skills as engineers. We looked if a community would grow around this, but that seemed not to be the case, most likely because it was too difficult and unreliable to use it.
You must understand that an internal programming level is something completely different than an official API provided to the users. The internal API may change with each release, even with each bugfix, and render your efforts useless. It is not reliable, not documented, not complete, not polished, uses internal terms, is not orthogonal and hard to use, and its very easy to make mistakes and loose your work (i.e. the Live set). Therefore we had to say that no API existed for the users to control Live.
Making such ann API from the internal layers is a significant effort and for MAX for Live we are doing that. We had to build an infrastructure for handling the user-made programs (patches) anyway, so we used the chance to extend MAX with objects to control Live. We took care to make a nice and understandable API and data model, we will document them, test them, fix bugs and keep them as stable as possible over time. So that we can say without shame, yes we provide an API.
the monodeck II was built using an open-source system with information provided by tk and the midibox community. however, i've yet to find any information about the monodeck II that was given back to the community (edit: i've found information on the hardware, but nothing on the software/communication). i have looked, because of my interest in getting under the hood with live. it was a bit disappointing to find nothing.The extensions of MIDIBOX software needed for monodeck II are documented here:
http://www.suckow.de/ralf/ledmatrix4x20/index.html
The actual software in the monodeck II is slightly different, but since I had no time to document it (again), I just sent the software as is to the people who asked, which were 3 or 4.
The huge Max patches which actually implement all the logic in Live are made by Robert and are his secret (his competitive advantage as musician, if you like). But this has nothing to do with the monodeck, with MIDIBOX, with ableton or with me. Most technical musicians keep their personal way of making music, their tricks, for themselves.
now we're being asked about how to improve a commercial product, after having been slighted on information regarding how to control our own devices. are you providing max for live for free? or do you want us to purchase it and tell you how you can make it better? how is this nothing more than a max for live advertisement being posted to the forum, when we already have a means to control live but are told it doesn't exist?You are right, that was a stupid move of mine. It has nothing to do with ableton. I was a little homesick about the MIDIBOX community, which I had no contact with for two years, and then I thought it would be cool to get some feedback on the API so that we could improve it, maybe even before the release. But I forgot that this is a completely non-commercial thing here, which I must respect. Also I became weak and allowed myself to show off with something I though would be cool in the eyes of the MIDIBOX community. You are right, please forget my post.
-
Hello Midiboxers,
sorry for entering the forum here with such a commercial topic,
but after making the 4x20 LED Matrix and especially the monodeck II
quite a few people contacted me about controlling Live. We couldn't
really help because the API used by monodeck II was proprietary and closed.
Now AKAI and Ableton have announced the APC40 which I think is something
you really won't like, or at least won't care about, because you make your own
stuff - devices which blew me off many times by their beauty or coolness, or both.
The 4x20 LED Matrix was a very early step in what ended now in the APC40.
But I personally was not involved in that project since end of 2006, because I
took care for something which could interest you much more - Max for Live.
My hope is that MfL will allow you to control Live from your MIDIBOX based
controllers in exactly the way you ever wanted. There is still a lot of work to
do to get it out, but during this time there will be a moment when the first
version of the API to control Live from Max will be stable enough to be published.
I will post it here asking you to make some comments which we could use to
correct some mistakes or inconviniences, of course, but most of all to see
what is missing and most wanted, to have an input for the second version.
What do think about that?
Melonenmonster aka. Ralf Suckow from Ableton
-
Hallo, TK hat die Button-Matrix wirklich günstig aufgebaut, standard printtaster für wenige Eurocent und einfach die LED oben mit Sekundenkleben draufgeklebt.
Is ja rischtisch geil! Auch dieses Verowire Pen Dingens.
-
Die Multimec Buttons gibt es jetzt auch mit fertig integrierter SMD LED.
(Damit entfällt das blöde Gepopel bis die LED drin ist ...)
Z.B. illumec 4F und aehnliche, ja die hatten wir auch probiert.
Leider kein perfektes Tastgefuehl fuer den praktizierenden Musiker
(wenn ich recht erinnere, subjektiv zu langer Weg, zu schwergaengig,
zu wenig Druckpunkt), und ausserdem die LEDs nur 2-polig, also
fuer RGB ungeeignet. Sonst aber schon ganz feine Taster.
Das Plexiglas bezog sich auf http://www.suckow.de/ralf/ledmatrix4x20/,
Bruchgefahr gibts da nicht, aber wie gesagt, zu viel Arbeit.
-
Hallo, ich würde gerne für den MB_SEQ eine Button/LED Matrix erweiterung bauen (http://www.midibox.org/forum/index.php?topic=7642.0). Ich suche günstige Buttons inkl. einer transparenten Kappe wo man eine LED einsetzten kann bzw. wo schon eine drin ist. Die Multimec Buttons + Kappe sind bei 64 Stück schon ganz schön teuer. Gibt es eine andere Lösung so wie es z.B. Monolake gemacht hat?
Was ist das eigentlich für ein Material was er verwendet hat (http://www.suckow.de/ralf/ledmatrix4x20/).
Viele Grüße
Jeffrey
Wir haben fuers monodeck II lange gesucht und vieles getestet, aber leider
keine "musikalischen" Buttons mit eingebauter LED gefunden. Deshalb die
LEDs jeweils daneben. Die dabei verwendeten Marquardt-Buttons kosten ca. 1EUR
und sind haptisch/timingmaessig Spitze, eher wie 'ne gute Computertastatur.
Bei der ledmatrix hab ich gefaerbtes Plexiglas genommen,
ist aber zu aufwaendig und nicht wirklich hell genug fuer
Einsatz am Tage. Wuerde ich nicht nochmal machen.
-
Thank you and, thank you!
Ralf
-
Hello,
since I didn't manage to program two cores in a MIDI Link
(ID 0 and 1, one forwarding point, one endpoint) while they
are linked, I disconnected them, set them to "enabled" mode,
replaced the application, and at the end activated the linked
mode using mk_syx, then reconnected.
Do you think there is a way to program them while they
are linked? This would avoid to open the device each time.
Thank you.
Ralf
-
I wonder if those lights aren't too bright? At least on the fotos it looks like they might blind your eyes in such a way that it's hard to see the buttons / read the panel any more, at least in dim light.
Best regards, ilmenator
Yes, on the photos they appear a bit lighter than in reality.
And you are right, a 1:4 software dimming is not enough.
The maximum setting allows playing in direct sun, 1/4 of that
is still too bright for the night. So, Robert invented and added a
hardware dimming which is a separate circuit for each color:
a square signal generator with adjustable busy cycle, which
turns the enable inputs of each of the shift registers on and off,
with a relatively high frequency, to avoid flicker. This not only
allows to setup the monodeck for performances at night, it also
allows to ajust the relative color brightness, which is important
for nice clean colors and the white balance.
Based on this setting, Robert can now fine-tune the brightness,
depending on the situation, with the software, quickly.
Ralf
-
*slaps himself*
I should've searched your previous posts :) http://www.suckow.de/ralf/ledmatrix4x20/index.html
Thanks!!
The software has been rewritten for the monodeck:
- based on midibox64 (not ...e) since we need no encoders but lots of pots
- the color of one, four, or all LEDS are set using MIDI notes
- there is a mapping which lets the buttons and LEDs be related to the same
note number, with a nice numbering scheme over the whole device,
which compensates for the anarchistic wiring
- the bitmap calculation is done when the note arrives,
so that the multiplexing routine is simpler and faster
- software dimming (1:1 ... 1:4, more is not possible since it flickers)
- two cores are linked, the software is modified so that one core
is responsible for LEDs/Buttons 0..63, the other for 64..127
- the schematic is a bit different, because the LEDs are RGB, not RGBB
- I disabled the button debouncing, else the LEDs would flicker
In general we would publish the info, IMHO, if somebody is
interested, there's just no time at the moment, Live6 is in the
beta phase, and then I'm on vacation until End of September
- lucky me 8)
Ralf
-
Hello TK, hello midibox community,
the monodeck II designed by monolake aka. Robert Henke
is finally done. Control software development (which is done by
Robert and is runnning on the host computer) will continue and
for sure see refinement after the experience from the first gigs,
but the device itself is finished.
Thank you very much for your hard and nice work.
MIOS and MIDIBOX are a great platform.
Have a nice life, you deserve it!
http://www.monolake.de/monodeck2.html
Ralf
-
Sorry everybody, it was a hardware fault.
The masses of the 8 buttons which repeated when pressed
were not connected to the ground. Instead, they were connected
to a LED multiplex line and got the on-off-signal from this connnection.
All the best,
Ralf
-
The modified application does a lot of other things, in assembler,
so C is not an option, but looking at NotifyToggle is an interesting point.
I tried it and the result is that MIOS_DIN_NotifyToggle is already called
repeatedly. So the autorepeater must be somewhere before.
Ralf
-
Hello Midiboxers,
I'm reprogramming a midibox64 to get all 64 DIN buttons
sending MIDI and nothing else, no menu etc.
All is well so far, but I could not turn off autorepeating
for the 8 buttons at pins 4-7 of SR0 and of SR1.
I have turned off normal autorepeating with MIOS_DIN_PinAutoRepeatDisable
and even reset bit 4 (MIOS_BOX_STAT_AUTOREPEAT) of MIOS_BOX_STAT,
all with no success.
I could not even find the part of the program that does the autorepeat
in my case, neither in the MB64 nor in the kernel. Perhaps I have to
try harder, I'm just a bit tyred after searching for too long.
Any help is highly appreciated.
Thank you.
Ralf
-
I've added a second file
http://www.suckow.de/ralf/ledmatrix4x20/annotated_mb64e_ledmatrix.inc
with comments. In any case, you should download the
"PICmicro® 18C MCU Family Reference Manual"
from microchip, parts of the adressing scheme and command
notation of this processor are a bit tricky, but effective, I'd say.
Beware of Thorstens Macros, and also that there exist some
shortcuts like W for destination d=0, don't know who defines them.
Concerning the panel, I'm happy that you find it cool.
In fact, it was really hard to take photos from the lighting
panel with the digital camera. There is no such thing as a "light
temperature" if you mix three different LED spectres.
In real live, the colors are much smother than in the photos.
And, the button are really white when off, not gray as in the
photo taken with flash. So I'd say its even nicer than the
photos can show ;) Maybe I'll make some analog photos
and scan them. Or put the panel on the scanner ???
Yours,
Ralf
-
Hello,
if somebody is interested, I've documented my LEDMATRIX 4x20 project,
which is an extension of MIDIbox64E hardware and software, at
http://www.suckow.de/ralf/ledmatrix4x20/
Yours,
Ralf
-
Duggle,
you made my day. Not only did you explain what
happens, but also made a very clever proposal.
I thought of some kind of amplification, but that
ULN2003 is really convincing. I didn't do electronics
for many years, so I'm not aware of the current
elements base and would have to search a lot.
I'll setup a test, It'll take some time,
but I'll let you know.
Thank you.
Yours,
Melonennmonster
-
That's true for the LED side connected through resistors with the Outputs.
But the other pin of the LED is also connected to an Output of the 74HC595.
So, since all pins of the LEDs are connected to the serial register outputs,
if you have a row or a column of LEDs active at the same time means that
in any case a single output must handle multiple active LEDs.
Melonenmonster
-
I just wanted to add that I'm not asking just for fun, but because I need to get the maximum brightness
out of the LEDs and thus need to know by what the currents are limited and how much I could push it.
Melonenmonster
-
Of course I'm just kidding, but please explain:
If you have 16 LEDRINGS with 11 LEDS each, and all are turned on,
then the current flowing into the common cathode pin is, during
each 1/16 time interval, 11*(5v-2v)/220 = 11*14mA = 154 mA.
But the 74HC595 is specified for 25mA input current at any voltage.
Why does it work? Where is my blind spot?
Or is the 25mA number only valid if all pins carry that current at the same time?
Yours,
Melonenmonster
-
Hello,
this is my initial post here, so first of all I'd like to say thank you to Thorsten Klose for all his great work. Super, Thorsten.
And of course to all you people sharing your knowledge.
I'd like to connect 144 LEDs to a Midibox64E, so I'll use a Variant of the LED-Rings.
Now, due to the multiplexing, the available current of 25mA is divided twice, first because multiple LEDs share a single
kathode-side return path, which is an output of a SR too, second, because the available current is divided in time
between multiple rows sharing a common anode.
Q1: My first question is: does the cathode-side output really need to be limited to 25 mA? Looking at the diagrams,
it seems to be not the case. And the current I measured with a single LED is indeed around 1/16th of what the
resistor of 220 Ohm would give. So if all LEDs are on, its 11 times the normal 14 mA LED current. So I suspect
the current going into the SR (on an output at around zero volt) can be much more than 25 mA. Is it limited at all?
Q2: Still with a 1/16 sharing, the LEDs are too dark. So I want to use 4 multiplexed rows of 28 LEDs
(only one of 3 LEDs in a row is on at a time). Is it difficult to modify the software for this purpose?
Could you point me to the places I need to change? I see the LED patterns, but where are the loops and
the link between the MIDI controllers and the SRs? Or is there a place to configure it? I'm a programmer,
so in the end I'll find out, but with a little help I'd feel much better when starting!
Q3: I want these LEDs to be independent of related encoders, but still need 13 encoders, will they get in
conflict? Where is the place to make a cut? I mean, if the encoders always send relative signals, I need
not to care? They are not linked internally?
Well, these are a lot of questions, Maybe that's an FAQ, but I've found nothing, although searched for many hours
(I had many other questions which I could finally resolve.)
Thanks alot!
Ralf
Controlling Ableton: APC40, Max for Live - what do you think?
in MIDIbox HUIs
Posted
Things like that are typical uses of Max, although I must say not all users of Max do care to make the interface as beautiful as the FL Gui.
Some of them make even nicer interfaces, though.
There is still a drawback of using LFOs to control Live parameters directly: you fill up the undo history, especially if many parameters are LFOed. We have no simple solution for this yet. Thus we avoided to control one parameter by another one, instead, let both work on a common signal processing.