On Fri, Mar 19, 2010 at 10:09 AM, alex stone &lt;compose59(a)gmail.com&gt; wrote: When I start jm2cv I got Usage: jm2cv <config> so the question is, how to start and use it exactly. Regards, \r

I do not really understand what the problem is with using MIDI control change for mixers. The resolution? For 2 data bytes there are 127 * 127 = 16129 steps. The number of channels? It's unlimited when using as much IOs as needed. IMO there already is a standard for all apps, it's called MIDI. IMO automation is overrated, it's useful, but OTOH how often is it needed to change settings during an opus? Most times a mix, selected synth etc. are fixed from the start to the end of an opus. For example, normally a musician plays an instrument dynamically by the touch or by using a volume pedal. Dynamic for the loudness seldom is done by a fader after the recording is done.

On Fri, Mar 19, 2010 at 3:16 PM, Tim E. Real &lt;termtech(a)rogers.com&gt; wrote: You can do all of this in Ardour *without* automation. --p

On Friday 19 March 2010 20:16:14 Tim E. Real wrote: <stripped the example> You use the wrong tool. With ardour: Slice the original take, move the ends to overlap a tiny bit with the new take, let the automatic fades do their job. Or move the boundaries edge to edge and use the fact that ardour has a slight fade-in/-out at region borders because they would pop otherwise regardless whether they overlap with another region or not. Works like charm and doesn't need automation.

Automation, especially audio automation, is extremely important. Some examples: When recording real musicians playing real instruments, you don't just record one take, you record several takes, then pick the best one and use the others to patch up the odd mistakes within the best take. Without automation, it is impossible to do this.

fons(a)kokkinizita.net wrote: Full ACK and IMO it's not up to the audio engineer to fade, but it's the task of the musician to play the instrument dynamically. In most cases an audio engineer makes a mix that is kept for a whole song, loud and silent passages are done by the artist, not by the technician.

alex stone wrote: "The weight of alternate responses seems to be geared toward a precise definition of the use of automation, for a particular use case, which is outside of the worklfow of some." Yes, indeed. I, for instance, is an electronic musician. I do not record stuff, I do not have takes. For me automation is close to 60-70% of the work, because my tunes are tunes of sound manipulation. Most electronic music is not note based music, that is, its beauty lies not in the notes it plays, but in the way sound is manipulated, arrangement is built. For me automation is as important as an ability to have a master sync. And automation is being put on a lot of things - on a lot of parameters of synthesizers, on volume, panning, gating and God knows how many things. And at the same time my music is not "experimental" music like they do with CSound. It is ambient, dub, it is usually pretty sweet to the ears (that is, no harsh, non-melodic sounds) and to a person who is not familiar with the process of creation of such a music it may be of a surprise that doing such music takes so much delicate tweaking. Louigi.

On Sat, Mar 20, 2010 at 9:06 AM, alex stone &lt;compose59(a)gmail.com <mailto:compose59@gmail.com>> wrote: I'm not sure the gist of the thread has been adhered to, but as someone who has sidetracked the odd thread in my enthusiasm, i'm no saint either. Nevertheless, citing ardour as the ultimate answer doesn't address the intent of the thread, which as i understand it was a question concerning the continuity of data streaming across apps. And although Ardour is a fine app, it's automation can be frustrating to use, for me at least. I've had a taste of using an alternative, and it's a lot easier to use, in my particular use case. The weight of alternate responses seems to be geared toward a precise definition of the use of automation, for a particular use case, which is outside of the worklfow of some. That immediately narrows the options for users, and forces those of use who work in a different way into "this is the way it is, and you'll have to find a workaround." Hardly the stuff of building a modular setup, with linux infinitely variable in the opportunities it offers to bolt things together in a manner the user wishes to exploit. I've been hammering away at midi since it started, and in the process of recording with midi driven projects, i discovered the following: 1.) Users do as much as they can in midi, before they record to audio. In the hands of an experienced user, a project can be "tuned" to a fairly decent result, before the recording to audio begins. 2.) No matter how much a user does to fine tune the midi, and there are some fine midi charts out there, the user still has to edit the audio after it's recorded, to further tweak the result into a closer resemblance of human playing. This is successful to varying degrees, dependent on the skills of the user, and what level of excellence he or she wishes to strive for, but in the case of recording orchestral work, it's been my experience that sorting out the velocities in the midi chart, and then using automation for audio to emulate swells, and smooth volume transitions gives the best result, generally speaking. 3.) Contrary to popular belief, midi is not the panacea for automation control. It's widespread adoption is more to do with the decisions taken by devs and companies in the commercial world, when midi finally got past the angst of commercial operators having to agree on something. As a protocol to render smooth automated lines, it too does its job with varying degrees of success. But it doesn't effectively render the smoothness associated with live playing. I know this as a former orchestral player, and have on many occasions had to render dozens of takes, simply to layer together enough audio to manipulate into some semblance of natural playing. 4.) Midi is a multiplexed format. If the user wants to automate using one single data stream, then like it or not, he is using 1 port=16 channels =0-127 bits of control data. In my recent tests, the CV data i wrote and used to automate a line gave a far smoother transition, from 0.0-1.0, and that was a single data stream. No extra channels, or the stepped result of using a defined data jump from 0 to 1 to 2 to 3, etc... On top of this, the user has to sort out which channel they're going to use, where they're going to send it, and which channel in which port they're going to attach it to. 5.) It's also my experience that users i've communicated with over many years, who write from midi recorded into audio, are likely going to write automation for volume, and maybe a little pan from time to time. This is very much dependent on the use case, but it's fair to say that those who require as smooth a volume change as possible don't get it using midi, at least to a decent standard of excellence. Again, relying on those years of use, and a fair degree of objectivity, i was enthused by the smoothness of using a CV stream to render volume transitions. One of those long held wishes that has come to life, and saved me a stack of donkey work in the process. 6.) Crossfading is neither here not there in a discussion about automation. It's the province of an app to provide an effective crossfade framework, something Ardour does well i might add. 7.) For electronic music writers in particular, but also for the wider user base, manipulating an external synth (and we are discussing a modular setup, yes?) via CV lanes seems to be an opportunity waiting to happen. The user adds a lane, names it to the control he wants to manipulate, and goes to work, recording smooth automation lines and getting the weird and sometimes original result from the synth. That's it. Add a lane, port it to a control and name it for easy recognition in the project. Couldn't be easier. and there's no "steps" (0-127) when the control is changed. 8.) I'm not wasting anymore valuable time on this,as it's clear any effort to do so would be futile in the face of the current status quo, and the intent to keep things as they are. Alex. The best technology might not always be the best choice. If you implement another technology/ format you also have to think about the environment. Commercial companies can't implement always the best technology, cause it isn't always the best choice in a business model. But this is also true for an community imo. The decision whether you should implement another technology should also depend in some way by your environment, the community. At least from a user perspective. As a user I don't have much benefit from apps with the best technologies if they don't support each other, don't support my hardware or my plugins. I don't know much about CV control. Is it really better then midi? Is it better for the Linux audio user, or do we have another format which isn't supported well within the community? At least you have to ask, as a community, yourself these questions. I don't have the answers, I don't want to be limited to protocols like vendors are. But I also don't like to see different apps not supporting the different plugin formats (ladspa, dssi, lv2), Jack versions, controller formats etc. You understand what I mean? \r

It is now at least 15 years past due for a new, far faster, and more expressive protocol.  Something based on the TOS connector or similar relatively inexpensive hardware interface that can handle 100x midi's traffic on a single, daisy chain-able connection.  I'd suggest 1394B, but in a setup and tear down every night scenario, I don't see that as being as rugged as a plastic optical fiber.

On Sat, Mar 20, 2010 at 12:45 PM, Gene Heskett &lt;gene.heskett(a)verizon.net&gt; wrote: uhmmm ... MIDI over USB or MIDI over ethernet is as flexible and fast as what you suggest, and already exist. The transport and physical layer aspects of MIDI are already going away. What remains is the actual message format and contents. --p

For a nice account on how things were done without computers see <http://www.soundonsound.com/sos/1995_articles/oct95/queen.html> I've never done anything *that* complicated, but the techniques described in that article were common practice in those days, no engineer would panic or complain when having to use them. Ciao,

For a nice account on how things were done without computers see <http://www.soundonsound.com/sos/1995_articles/oct95/queen.html> I've never done anything *that* complicated, but the techniques described in that article were common practice in those days, no engineer would panic or complain when having to use them. Ciao, -- FA It is fun to read how things were done back then and it certainly influenced the type of music that was done, which is worth analyzing and thinking about, but I am not sure that is inspiring. I am myself now a bit interested in a hardware setup, I have two grooveboxes and plan to buy a mixer two get those two and a laptop together into one sound and I can imagine that making just one tune can be a difficult process. But romanticizing this process is the same as saying - "Remember when getting from Europe to India took months?" It is a different situation when you know that EVERYONE goes through this. It is an absolutely different story when you know for a fact that users of another operating system have good working solutions of the problem you are having. And so not having automation is a bit weird. As shown above, automation is essential in certain very widely spread types of electronic music when you need to turn many knobs at the same time to achieve the result. Asking 15 of your friends to help you do this during recording is a bit too much I think though it might make for a good record into the book of records.

It is a different situation when you know that EVERYONE goes through this. It is an absolutely different story when you know for a fact that users of another operating system have good working solutions of the problem you are having. And so not having automation is a bit weird. As shown above, automation is essential in certain very widely spread types of electronic music when you need to turn many knobs at the same time to achieve the result. Asking 15 of your friends to help you do this during recording is a bit too much I think though it might make for a good record into the book of records. It's not true that this kind of automation really is done by heavy mixing. Yes, e.g. when I used my Atari ST and Cubase I had a Window with MIDI SysEx controllers e.g. for my Oberheim Matrix-1000. A separated MIDI port and that it was. This kind of automation is missing for Linux. But I wish to have some examples off all that music that reportedly makes a lot of usage of automation for the mixer. There isn't much of that music. Doing this is unusual, it very often is done by inexperienced musicians and hobby engineers because they guess it's the way to do it like this, once they are more experienced they won't do it by automation any more. Ralf Hey Ralf! I do not think you understood me. I am speaking about automating parameters of various synths. If you want the cutoff frequency to change or wabble and at the same time have the resonance move and all of that you want to feed into a controller that would LFO all that against the volume of another sound so that both come in and out - all of this takes lots of automation to get to the result. How can this be possible without automation I do not know - only if you ask several people to help you and train them to perform automations in real time. Louigi.

Less SysEx even is a problem when not using separated MIDI IOs. Quantisation can't be used when recording, resp. playing such recorded data.

For filters etc. most times just 128 steps are enough, hardware synth tend to use just 128 steps even when using SysEx instead of CC.

This is wrong. The number of bits in a parameter is unrelated to where and what some filter is or is not tuned to.

Indeed a B3 emulated by an Oberheim Matrix-1000 might be no good choice, OTOH because of the automation, you won't have any synth with a good B3 emulation to change 20 parameters during a song, while for any "synthetic" sound e.g. from an Oberheim Matrix-1000 you might wish to change a lot of parameters during a song and changing filter parameters for "synthetic" sounds 128 steps are enough.

ralf.mardorf wrote I would like to have one, especially because I fear that one of the CME microchips someday will go west, but I guess that the CME microchips make the big difference to virtual analog synth.

Date: Mon, 22 Mar 2010 22:56:21 +0100 From: ralf.mardorf(a)alice-dsl.net To: nickycopeland(a)hotmail.com CC: jens.andreasen(a)comhem.se; louigi.verona(a)gmail.com; linux-audio-dev(a)lists.linuxaudio.org Subject: Re: [LAD] automation on Linux (modular approach) Keep in mind that there are hardware MIDI control panels that anyway would need a bridge for MIDI in to internal Linux cv. Pushing virtual knobs is a pain because of several issues, e.g. because of the mouse resolution. I would like to have one, especially because I fear that one of the CME microchips someday will go west, but I guess that the CME microchips make the big difference to virtual analog synth. A nice Feature is a vector control. Just having a kind of MIDI vector mixer that would use 4 already existing Linux synth would be nice, e.g. 2 instances of fluidsynth and two instances of a polyphonic calf monosynth. Btw. http://www.dv247.com/news/Dave%20Smith%20Instruments%20(DSI)%20at%20Digital…

There is no way to refer to anything higher level, to say e.g. this is a control message for note #12345 that started some time ago.

I still feel that the CV should remain floats at native sample rate and apps that want to quantise should just pull out every n'th sample.

Hm? And how do we use the automation? By mouse or by hardware MIDI controllers ;)? If the hardware MIDI controller would define the start and end point and cv uses a movement curve it isn't really manually control, but having a resolution of 14 bit for MIDI might be smooth enough and manually movements could be recorded by the sequencer.

Just 128 steps for filter cutoff for an oscillating emphasis does not work well if it needs to be tuned exactly to an VCO/DCO, it is basically never in tune and was a big grumble about the early programable analogues since they only had 64 to 128 steps available for filter frequency from their AD control converters and memories. Two bytes does go a long way towards the goal and it pretty much on if it is not applied as literal Hz but as a power scale. Somebody asked which soft synths would support this kind of feature, Bristol will be implementing CV in the next release for subset of its emulators. Regards, nick.

fons wrote: "Sequencers do this, but the possibilities are usually rather limited." Hm. Man, I must challenge this statement. "Limited" is of course a very general and relative term, but in sequencers I used - FL Studio, Ableton Live and actually even latest LMMS - you basically can automate almost any parameter, almost any knob or control you see.

By automation I do not necessarily mean the software remembering how you turn knobs - it can be just a graph. When it does remember your turning, it still stores it as same graphs, at least in FL Studio.

Both are still limited in the sense that you have to define that data explicitly. Ciao, -- FA I am sorry, I do not understand what kind of limitation you are speaking about. I may not be a programmer and perhaps I lack knowledge and understanding of some concepts like this defining data explicitly, I do know that currently on Linux I cannot do a whole class of things. So if I wanna do an ambient tune and use Zyn as my sound source, I would not be able to automate, either in real time or non-real time mode in a graph some of its parameters. And I do need that functionality. It can be "limited", but this is all I need, since just playing notes is no good. I need to work with the sound itself. This is what automation is for me, it is not about mixing, it is about manipulating sound itself. Again, maybe I am not getting something. Louigi.

I'm with Louigi on this - I'd like to set up a sequence in whatever sequencer I'm using and draw graphs to control cut-offs modulations etc etc in some softsynth BEFORE the sound is output/recorded. But because I can't do this, I have to settle with recording the audio of the synth into ardour, and then use automation to control the params of various LV2/LADSPA plugins. It has provided some interesting (to me) results :-) http://jwm-art.net/art/audio/qtest_fallibility.mp3 but I doubt the engineers (or real musicians) amongst you will approve. James.

On Tuesday 23 March 2010, Ralf Mardorf wrote: Likewise, Hi James. I thought the percussion was very good, but the keyboard came in, then the mp3 distortion was obvious and I killed it. But the kill wasn't clean and I had to hunt the player down with htop and kill the top copy of the player, it was left looping about a bar. I wonder if a FLAC or ogg would have torn up the keyboard sound like that? I'd like to try one of those formats myself as it did sound like the beginnings of something worth listening to. > very good composition, very good arrangement and a good recording. I > really do like it, a FLAC or WAV for private listening is welcome :). > I planed to do something similar using Linux. Using hardware synth > controlled by the ATARI ST Cubase SysEx Windows to record changes for > the filters etc. and using an anlog mixer a song like yours is easy to do. > Perhaps this SysEx thing is needed for Linux sequencers too. > Anyway, you were able to this recording using Linux. > > Cheers! > Ralf >

recorder and editor'. Never seem such an app, but I'm sure it would be useful.

I dunno, but perhaps for Muse it's the way like it is for Qtractor? You need to use the mouse and move the graphic of the recordings at the end and the beginning of overlapping tracks [1]? IMO this is much easier than moving a virtual fader. But ok, everything about this was written and you prefer automation, that's ok, but you can see that some people do it without automation. It's possible, nothing is missing. Ralf

fons(a)kokkinizita.net wrote: Full ACK and in addition I would use a subgroup for the channel of the regular track and for the channel of the track of the copied fragment.

Even if heavy mixing is required, e.g. for an audio collage I guess it's more musical to do such heavy mixing with an external (not necessarily analogue) mixing console.

Some kind of heavy mixing for current chart music needs automation that isn't possible by Linux now, if this is needed it can be done by recording the different mixes and then by piecing together this recordings, because this kind of music itself is pieced together.

There are other areas as well that will become more relevant: - proper syncing, in all its forms - save format backwards compatibility

On Fri, Mar 19, 2010 at 12:32 PM, Philipp &lt;hollunder(a)lavabit.com <mailto:hollunder@lavabit.com>> wrote: Excerpts from alex stone's message of 2010-03-19 10:09:04 +0100: good patchbay. Thanks for telling us about this app Alex, it sounds like it could become an important piece in the puzzle if cv gets more popular. On the topic: I think once jack_session is established and we have a well working session management for every app automation is one of the things that will need more attention. There are other areas as well that will become more relevant: - proper syncing, in all its forms I agree about the fact that proper syncing (Jack Transport), is likely even more important then automation for the modular approach, it has it's limitations right now...