Jump to content

Melonenmonster

Members
  • Posts

    25
  • Joined

  • Last visited

    Never

Everything posted by Melonenmonster

  1. 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.
  2. MfL will be the only offical, legal, reliable and supported way to do it. 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. 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. Well, a nice and quite original design. Not one of the Mackie HUI lookalikes you see each day. No, there's the usual control script for it. 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. The software layer still exists, although it has changed. I cannot say if the hack will keep working. 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
  3. 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
  4. 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. 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
  5. 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.
  6. 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 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. 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.
  7. 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
  8. Is ja rischtisch geil! Auch dieses Verowire Pen Dingens.
  9. 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.
  10. 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.
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
×
×
  • Create New...