"Logic 7 does not support hardware MIDI"- Agree?

[editbrain]

Asher, who are you to say when and why people have to move on?

 

I mean on GS you admitted that the clock was broken, but you keep defending Apple, and you compare midi gear to an electric guitar. What gives?

 

if it were time to move on don't you think we would have flying cars, and not play electric guitars? did i hear a real piano from my wife just now? NO THAT WAS HER iPHONE Ring Tone. <--NOT!

Edited June 25, 2007 by editbrain

[David Nahmani]

It's not just about the number of velocity layers...

 

I have done a lot of MIDI programming for Yamaha keyboards, and trust me, you can go insane doing that kind of work.

 

Just the way MIDI is designed has its limits. For example, the fact that to draw a pitch bend of volume fade, you need 30 or 50 events. If you think Photoshop vs Illustrator, if there was a new musical language with a vector approach to pitch bend of volume fades, all you would need is 2 or three events: from where, to where, and what kind of curve. And it would be sooo easy to adjust it. Kinda like what you see in hyperdraw, with two nodes and one curve in between. Except hyperdraw has its limitations too...

 

But really, I wasn't suggesting we should scrap MIDI altogether. Keep it around for as long as some producers will need it, which could be a century or two or more, what do I know. Just create something else...

 

OK maybe I shouldn't have said supersede...

[editbrain]

David, I mean. Midi is kinda like the wheel.

 

New cars come out, but guess what, they have wheels. From Asher's comments and conflicting defense of this issue. You would think that the 2008 models would do away with wheels. because we should move on. But what about the roads we have laid? hmm...

[David Nahmani]

That aside I feel that MIDI is ignored both by Apple and largely by this forum.

While I can't speak for Apple, I'm not sure why you feel that way about this forum. After years of fighting and kicking and screaming trying to figure out my way around MIDI, I feel I have a pretty good handle on it since my gig at Yamaha, and I usually try to help people having MIDI questions.

 

Anyway, thanks for your apologies, they are appreciated and accepted, no worries at all. I really think that at least on my end (I didn't even read the whole thread and the original Ski and Ashermusic posts to be honnest), it all came from a misunderstanding. Maybe I should read the whole thread before posting even a simple one-liner in the future! My apologies (my turn)!

[johan]

I'm not saying get rid of it, I'm saying come up with something better that hopefully will slowly become the new standard.

 

I believe OSC or equivalent is the answer but as it's open source I guess it's unlikely to be adopted by a corporate like apple, Jobs may be an old hippie but his lawyers arn't. Interestingly, in relation, Ableton has given their blessing to Liveapi http://www.liveapi.org witout actually endorsing it.

 

Cheers

[ski]

After years of fighting and kicking and screaming trying to figure out my way around MIDI...

 

What other way is there around MIDI? Yes, new protocols being developed by third parties. Fine. But MIDI as it currently exists is a force to be reckoned with by virtue of hundreds of millions of existing pieces of MIDI equipment. And let's not forget that Audio Instruments are also played via MIDI (or a very MIDI-like version of data). Thus, a VI string part can be ported out to external MIDI devices (whether it's via 5-pin DIn or a MIDI network) to double it/thicken it.

 

Until a new, univerally adopted protocol is adopted absolutely unilaterally by MI manufacturers, I think MIDI is going to be around for a long time. Actually, the clock issue aside, unless all someone does is record straight-up audio, I think we're all doing quite well with MIDI, don't you?

 

EDIT:

 

I didn't even read the whole thread and the original Ski and Ashermusic posts to be honnest

 

That's OK. Ignore me. I can take it.

 

[sniffle]

[johan]

Midi is kinda like the wheel.

 

Yes but see there's nothing to say that it wasn't updated and improved, documentation is somewhat poor from the dawn of man

 

Joking aside I doubt Midi will ever completely disappear from any DAW but the changes will probably happen within software like Bidule etc

 

And I don't think Apple ignores MIDI anymore (or less) then any other manufacturer do (or don't). I think Asher is right here it's not the future so it's tolerated but not encouraged.

[David Nahmani]

Ski, I meant trying to figure out how to use MIDI, not trying to figure out how to avoid using it.

 

OK, guys, maybe we should talk about politics or digital vs analog or the benefits of 192K, or intersample peak distortion in 32 bit floating point engines, are you with me?

 

I think I need to listen to some Bill Hicks right now.

 

"What do you say we lighten things up and talk about abortion? You know... I feel like I'm losing some of you here, and I want to win all of you back with this one. Let's talk about abortion. Let's talk about child killing, see if we can get some chuckles rippling through the room here. Let's talk about mass murder of young unborn children see if we can get one big healthy gut laugh: Mwahahahaha....".

[ski]

Ski, I meant trying to figure out how to use MIDI, not trying to figure out how to avoid using it.

 

Ah, thanks for clarifying.

 

But... "how to use MIDI"... You mean, 20+ years later and there are still questions?

 

(hee hee)

[David Nahmani]

But... "how to use MIDI"... You mean, 20+ years later and there are still questions?

Well.. with certain pieces of equipment... yes, definitely!

 

One example in mind: when programming for Yamaha, one of our guidelines was to never have redundant information. That means never send twice the same event. That guideline alone makes it a HEADACHE to program MIDI CC in Logic.

 

Try to program fades and pitch bend curves under those conditions. Virtually impossible in Logic (Take MIDI volume: if your volume is set to 0dB at the top of the track, how do you draw a fade down that does NOT start by sending a 0dB event?!). I ended up having to use hyper draw and event list, and constantly having to correct the events generated by hyper draw in the event list. You have no idea the sheer amount of hours/days/weeks I have wasted on that stuff.

 

Update: well that was a bad example, that's actually pretty easy to do in hyperdraw alone. OK so I don't remember exactly what it was, but I remember having bad headaches, for sure. Oh yeah and editing pitch bend information with hyperdraw and having it come back to 0? forget it.

Edited June 25, 2007 by David Nahmani

[editbrain]

Midi is kinda like the wheel.

 

Yes but see there's nothing to say that it wasn't updated and improved, documentation is somewhat poor from the dawn of man

 

Joking aside I doubt Midi will ever completely disappear from any DAW but the changes will probably happen within software like Bidule etc

 

And I don't think Apple ignores MIDI anymore (or less) then any other manufacturer do (or don't). I think Asher is right here it's not the future so it's tolerated but not encouraged.

 

okay?

[ski]

I'd say that the guideline is f-ing nuts. OMG... If they had guidelines like that for (the company I occasionally do programming for) I'd go insane.

 

As you know, if you have more than one PB gesture in a region it would be impossible to have a continuous stream of PB data where the point at the end of the first gesture and the point before the second gesture were not both zero (64). Let's see... the workaround... since Logic is prevented from drawing a continuous line of events to 'connect' PB events between individual regions, the second region that has PB data would have to be separated and then start at PB=65 at the start of the actual bend. That would suppress the starting value of 64.

 

Jeez...

[David Nahmani]

Yeah I don't remember exactly but what a hassle when copying regions, merging aliases, copying pitch bend automation within a region.... when you have to create a pitch ramp up at the beginning and down at the end of every single line... along with expression ramps... to simulate a vocalist coming in and out... you can get an idea of my nightmare.

[xs4is]

Hi all.

 

Fun thread. Ski, great points as always. Asher, great points but your delivery needs work, LOL!

 

Ski has given me tutorials in the mysteries of MIDI before and I have had to say, "I don't have time to learn a new language. Maybe when I have some excessive free time."

 

MIDI doesn't seem very friendly to me. Not that I'm bad mouthing it, quite the opposite really. I'm amazed by it. Probably the same kind of amazement illiterate people in the dark ages had about folks who could read. I really really really wish that I completely understood all there is to understand about MIDI. For now, at my level of experience, my plug-ins and "in the box" approach is good enough.

 

Having established how thoroughly inept I am with MIDI, I have to ask this:

 

Can't you all use some thing like Big Ben (which I believe to be a dedicated external MIDI clock)? If not, could you dumb down the reason for me?

 

Thanks for listening.

X

[ski]

X-man,

 

I'mma have ta give ya a MIDI clock lesson offline... Big Ben is for a different kind of clocking.   However, the kind of stability that a wordclock device like the Big Ben is something that people could only wish for when it come to a wobbly (but useful) thing like MIDI clock.

 

In short, MIDI clock is a stream of MIDI data which tells an external device (like a drum machine, other sequencer, or arpeggiator in a synth) what the tempo of the master device (Logic) is. MIDI clock is sent almost like a series of "tempo pulses". The resolution of MIDI clock is 24 ppqn, which means that for every quarter note, regardless of tempo, the slave device is sent 24 (supposedly) equally spaced MIDI "pulses" and these tell the slave device what the tempo of the master (Logic) is. So a slave device is updated 24 times per quarter note as to the speed of the master's tempo.

 

At 60 BPM, each quarter note lasts 1 second, so 24 of these MIDI "pulses" are sent via MIDI to the slave device each quarter note's worth of time to establish the tempo in the slave device. At 120 BPM, you also get 24 "pulses" per quarter note but they occur with greater frequency than at 60 BPM. Twice the frequency in this case.

 

The actual data for a MIDI clock "pulse" is a single byte wide and is the smallest possible kind of MIDI message that can be transmitted. This was done intentionally, so that the smallest possible amount of data would need to be injected into the MIDI stream so as not interfere too much with the timing of other MIDI data in that stream (controllers, notes, etc.).

 

 

[edited for mistakes, clarity, yadda yadda]

[xs4is]

to ski: oooOOOOOooooh!

 

Then what the hell is a word clock? LOL!

 

You're all geniuses. If you can understand most/all of this thread, then you are an absolute genius. You should be payed more, women (or men) should flock to you, and men (or women) should want to be you.

 

I would love an offline lesson ski, but DO NOT waste your time on me until that rarest of days where the stars, planets, politicians, Mac and PC, etc etc, align. Then and only then will we both have a minute for the one way discussion where you will go, "when you do "a" this will happen," and I'll go, "what's "a" again?" Basically, I don't want to waste your time my friend. You are a busy guy.

 

X

[David Nahmani]

Ski, plEASE, if you're going to give a lesson, do it here so we can all read it!

 

Wordclock is a digital audio clock. In digital audio, you're sampling the value of an analog electrical signal X times per seconds. X is your sampling rate (for example 44,100Hz for CDs). Each time you sample that value, you code that value in binary: a bunch of zeroes and ones the computer can understand. That value, the sample, is called a "word". If you use 16 zeroes and ones to code that sample, you're working with a 16 bit depth. If you use 24, that's a 24 bit depth.

 

So when you need to make sure several digital devices all spit out their words at exactly the same time, you use a word clock. Any digital device has a clock, but some clocks are better than other. Big Ben is a great clock made by Apogee and used by many studios to synchronize all their digital audio gear.

 

In my early, early days in the domain of digital audio, I remember transferring a DAT tape into a computer without setting the computer to slave to the DAT clock. Instead, the computer was using its own internal clock, and the DAT its own internal clock. The result, which had me pull my hair for days (until someone more knowledgeable explained to me what it was I was doing wrong), was a bunch of clicks in the middle of the audio: here and there the computer had to drop a word or come up with a word when there was none!

[xs4is]

Thank you for the explanation David. Much appreciated.

 

I should probably go to school. LOL!

X

[David Nahmani]

You are in school! This is Logic Pro School! Hahaha....

[ski]

X4,

 

Now pay the nice man and show your ticket to the lady at the turnstile.

 

[Ashermusic]

Asher, who are you to say when and why people have to move on?

 

I mean on GS you admitted that the clock was broken, but you keep defending Apple, and you compare midi gear to an electric guitar. What gives?

 

if it were time to move on don't you think we would have flying cars, and not play electric guitars? did i hear a real piano from my wife just now? NO THAT WAS HER iPHONE Ring Tone. <--NOT!

 

Guys, guys,....

 

1I am not saying that I think it is right if midi clock goes away in Logic, or in this case, never gets repaired to its previous state. I did not personally order or advise Apple to do it. I do not have that power.

 

I am just saying that it is what is happening and in a technological age some things get preserved and some get discarded according to developer's priorities and marketing decisions.

 

Once again, many people were very angry when VST and Windows support were abandoned in Logic but sooner or later they either adapted or moved on.

 

It is what it is.

 

I do agree totally with David and Ski however that midi itself is creaky and could do with a major overhaul. We are using 30 year old technology to run modern computers and hardware and I am convinced it could be much better.

[johan]

Midi is kinda like the wheel.

 

Yes but see there's nothing to say that it wasn't updated and improved, documentation is somewhat poor from the dawn of man

 

Joking aside I doubt Midi will ever completely disappear from any DAW but the changes will probably happen within software like Bidule etc

 

And I don't think Apple ignores MIDI anymore (or less) then any other manufacturer do (or don't). I think Asher is right here it's not the future so it's tolerated but not encouraged.

 

okay?

 

My point being that very few things are created perfectly (Jessica Alba being a noteworthy exception here) and most things have been improved and perfected over time, for all we know the wheel could've been square when it was first invented.

 

MIDI is pretty much the same as it ever was and it's a shame that DAW manufacturers are not adopting new protocols. OSC seems quite exciting to me although admitedly I've never had a chance to use it.

 

Sorry if it came off as a bit confused or in any regards flippant, if so my apologies.

 

Cheers

 

Johan

[ski]

I haven't examined any of the MIDI alternatives, but I've been thinking about this idea of revamping MIDI, and here are some of the most significant limitations of MIDI as it exists now...

 

1. Limited Bandwidth (384 kbytes/sec)

- could be much faster to deliver information from controller to target synth/plug more instantaneously. But this would mean that the scan rates of keyboard controllers would need to get much faster in the future. USB offers much faster data transfer rates, but USB isn't a dedicated system as MIDI is. The high data rate of USB partially makes up for the fact that it's a non-dedicated system for delivery performance-oriented data. On the non-dedicated front, it's probably not a good idea to be printing out something on a USB printer, running a USB monitor, and powering that USB drink cooler all at the same time while you're trying to accurately record a musical performance on a USB controller...

 

2. Limited Resolution

- velocity, modwheel, pitchbend, and other controllers are quantized to have a minimum (standard) of 7 bits of resolution. That's only 127 steps to convey performance nuances. In the case of velocity there are only 126 steps (zero means "note off"). And in the case of continuous controllers specifically, there is a protocol for 14-bit resolution (MSB and LSB), but not every keyboard/controller manufacturer implements this, and not every target synth/plug reacts to the LSB.

 

3. MIDI is a Serial Protocol

- performance Data (notes/controllers),timing data (MIDI clock, MTC), MMC, and sysex are all intermingled and transmitted on the same cable. A target synth has to examine every single byte of data it receives to see if it's supposed to react to it, and because MIDI is serial, it does so one byte at a time. So if a synth expecting to react to data on Ch. 1 is busy looking at (and then ignoring) data on Ch. 2 and Ch. 15, as well as looking at MIDI clock data (which it may or may not need to react to) your synth may seem to react sluggishly to your live playing. This is called a "MIDI bottleneck".

 

So, to insure the most accurate real-time performance, timing signals (MIDI Clock and MTC), to name two, should never really be transmitted on the same cable as your performance data. But there are probably zero synths on the market that have two MIDI inputs, one for clock/MTC and the other for "performance data".

 

Were this to be the case it would be a step in the right direction towards making MIDI a parallel system, where the target synth could react to MIDI data in a parallel manner.

 

===========

 

MIDI has other shortcomings, but still, it works pretty damn well just as it is. Amazingly so, IMO.

 

Regards to All,

 

-=sKi=-

[David Nahmani]

And Ski, do you have any opinion on my "vector" idea? In my opinion the very design of MIDI is limited in that it needs to send a collection of discrete events to approximate a fade or a curve, rather than simply giving a couple of parameters describing the curve.

 

 

Let's take a fade:

MIDI:

1 1 1 1 Volume = 85

1 1 1 61 Volume = 84

1 1 1 121 Volume = 83

1 1 1 181 Volume = 82

.

.

.

2 1 1 1 Volume = 1

 

vector-style alternative

1 1 1 1 Volume goes to 1 by the time it reaches 2 1 1 1, with a curve of 1.

[ski]

David,

 

If I understand your concept, I think it would be fantastic for, say, Logic to allow for this kind of thing in Hyperdraw mode. It reminds me of the way that smooth automation curves can be created in Logic using the automation (curve mode) tool. So, put a point here (A), put a point there (B). A data stream is then interpolated linerally, say, to start. Then alter the curve as desired. No intermediate points are seen visually. But you'll arrive at point B in time, regardless of the curve shape.

 

How the data is generated could be further tweezed if there was a way to adjust the rate-of-arrival (i.e., rate curve) if you wanted to get really picky about it . Similar to the choice of portamento curves offered by some synths, you could have linear, exponential, reverse exponential, etc. rate curves.

 

But for realtime performance I don't know how a vector approach would work because it seems to me that, by design, the vector approach requires pre-planning. One of the good things about MIDI is that a synth reacts "in the moment" to your performance without requiring much if any advance planning. So unless I'm misunderstanding your concept, it seems that a vector approach represents a conflicting paradigm when it comes to MIDI --- real-time performance vs. preplanned preprogrammed performance. But again, from a GUI point of view it would make things look much neater and perhaps give more predictable results.

 

[edited]

[ski]

I am not saying that I think it is right if midi clock goes away in Logic, or in this case, never gets repaired to its previous state.

 

Glad to hear this!

 

Again, when it comes to MIDI clock, lowly as it is, if people are complaining that Logic's transmission of MIDI clock is extra-sucky, then, I'm tellin' ya, it can't be a difficult thing to make right. Think about this...

 

Considering all of the other complex things that Logic does, including generating an elapsed SMPTE bits display in real time at a rate that's much faster than that required to generate MIDI clock data, it can't possibly be difficult to generate MIDI clock --- 24 single bytes per quarter note of tempo -- and do it with optimal timing.

 

I'm so convinced that MIDI clock generation is such a simple thing to calculate in code that nothing short of an explanation from Dr. L. himself as to why it can't be done accurately would convince me otherwise.

 

But then again, we have bugs that are 10+ years old in Logic, so I think it's fair to say that there's a certain amount of back-burnering, perhaps even laziness afoot when it comes to the programming/fixing of this code. Either that, or, they've painted themselves into a programming corner to the point where only a major re-write could solve some of these problems (I know this as a former programmer myself).

 

Still, outputting 24 bytes per second, and accurately so? Should be a walk in the park.

[Ashermusic]

I am not saying that I think it is right if midi clock goes away in Logic, or in this case, never gets repaired to its previous state.

 

Glad to hear this!

 

Again, when it comes to MIDI clock, lowly as it is, if people are complaining that Logic's transmission of MIDI clock is extra-sucky, then, I'm tellin' ya, it can't be a difficult thing to make right. Think about this...

 

Considering all of the other complex things that Logic does, including generating an elapsed SMPTE bits display in real time at a rate that's much faster than that required to generate MIDI clock data, it can't possibly be difficult to generate MIDI clock --- 24 single bytes per quarter note of tempo -- and do it with optimal timing.

 

I'm so convinced that MIDI clock generation is such a simple thing to calculate in code that nothing short of an explanation from Dr. L. himself as to why it can't be done accurately would convince me otherwise.

 

But then again, we have bugs that are 10+ years old in Logic, so I think it's fair to say that there's a certain amount of back-burnering, perhaps even laziness afoot when it comes to the programming/fixing of this code. Either that, or, they've painted themselves into a programming corner to the point where only a major re-write could solve some of these problems (I know this as a former programmer myself).

 

Still, outputting 24 bytes per second, and accurately so? Should be a walk in the park.

 

My standard joke about Emagic used to be that their motto was: "The impossible we do easily. The basic will take a little longer."

 

I fear it is still true.

[Fred B]

Still, outputting 24 bytes per second, and accurately so? Should be a walk in the park.

In a multi-tasking environment this is true only if the MIDI clock generator runs with highest priority. But I suspect that MIDI processing in Logic has rather low priority for the benefit of audio processing.

[fader8]

So, to insure the most accurate real-time performance, timing signals (MIDI Clock and MTC), to name two, should never really be transmitted on the same cable as your performance data. But there are probably zero synths on the market that have two MIDI inputs, one for clock/MTC and the other for "performance data".

 

This is exactly how Kyma works. The hardware has dedicated MIDI/MTC/clock, LTC and VITC inputs. Then the software, running on your Mac, sends very high resolution control parameters to the hardware via firewire.

 

The sequencer, (actually more like a scheduler) also locks to the SMPTE coming in via FW to the Mac. So you can draw highly detailed control signals in perfect sync. In fact, you can create control automation by envelope following complex audio signals, apply it to your synth or sampled sound and have this in perfect beat sync too.

 

It amazes me that the MMA have been dragging their collective feet on the HD-MIDI standard. In the meantime, mainstream programs like Max/MSP, Supercollider, and even Reaktor have implemented Open Sound Control to some degree. Now even a few hardware manuf's.

 

Looks like it's in the hands of the industry politicians. We'll have to wait and see. Anyone interested in a new career as a lobbyist? C'mon. How about you ski? . . . . Yea, that's it. I nominate you ski!

[David Nahmani]

But for realtime performance I don't know how a vector approach would work because it seems to me that, by design, the vector approach requires pre-planning. One of the good things about MIDI is that a synth reacts "in the moment" to your performance without requiring much if any advance planning. So unless I'm misunderstanding your concept, it seems that a vector approach represents a conflicting paradigm when it comes to MIDI --- real-time performance vs. preplanned preprogrammed performance. But again, from a GUI point of view it would make things look much neater and perhaps give more predictable results.

You're correct, this wouldn't work for real-time performance! I was thinking about graphical automation.