12 Jul
2014
12 Jul
'14
12:39 a.m.
Just looking through the midi messages used by the Mackie and other
controlers. It appears to me that it is designed to be used on it's own
physical midi channel as it uses (up to) all the logical midi channels (1
to 16) and so could not work running through a midi kb for example. It is
just the faders that do this using the pitch control on each channel, all
the switches, lamp signals and encoders are on channel 1 (or 0 if you
like) which would also conflict with some of the older KB like the DX7
which use only channel 1 also. Now obviously, if the controler is a USB
device, it creates it's own midi port anyway. I took a look at Ardour
(cause that is what I use to record) and it has a port dedicated to the
controler (and other things) so that is not a problem.
My question then is do all applications that can be controled by midi have
a dedicated port for control? (well most anyway The non-group of
applications accepts midi control of transport, but not the mixer which
wants midi converted to CV first... making it effectively not controlable
via a control surface without some sort of SW interface to take care of
banks etc.) Hmm, directly controling jack transport might be an idea.
--
Len Ovens
www.ovenwerks.net
12 Jul
12 Jul
1:01 a.m.
On Fri, Jul 11, 2014 at 6:39 PM, Len Ovens <len(a)ovenwerks.net> wrote:
Just looking through the midi messages used by the
Mackie and other
controlers. It appears to me that it is designed to be used on it's own
physical midi channel as it uses (up to) all the logical midi channels (1
to 16) and so could not work running through a midi kb for example.
MIDI Machine Control is even more demanding, although it is all sysex, and
MIDI Timecode has always been recommended to be delivered on its own cable
(if using serial MIDI at least).
4:35 p.m.
On Fri, 11 Jul 2014, Paul Davis wrote:
On Fri, Jul 11, 2014 at 6:39 PM, Len Ovens
<len(a)ovenwerks.net> wrote:
Just looking through the midi messages used by the Mackie and other
controlers. It appears to me that it is designed to be used on it's
own physical midi channel as it uses (up to) all the logical midi
channels (1 to 16) and so could not work running through a midi kb
for example.
MIDI Machine Control is even more demanding, although it is all sysex, and MIDI
Timecode has always been recommended to be delivered on its own cable (if using
serial MIDI at least).
I can see that. My last use of MTC/MCC was syncing a sequencer to physical
tape. There would not have been "sample accurate sync" anyway. For that
matter, the sequencer would have given me the transport start and stop,
but the sync box was set for time signature and b/m. when playing back it
would have been the only thing on the input line to the sequencer.
I don't miss the the tape machine at all.
In many ways the USB line has replaced the MIDI serial line for most of
todays MIDI work. I think this is a good thing as it means each MIDI unit
has it's own port. The one thing the MIDI port has is groundloop
protection, USB does not.
The only thing I use the physical MIDI port for anymore, it keyboard input
(DX7, drum pads) and output to external synth. Everything else is a
virtual MIDI line, including the current project.
--
Len Ovens
www.ovenwerks.net
5:09 p.m.
On Sat, Jul 12, 2014 at 10:34 AM, Len Ovens <len(a)ovenwerks.net> wrote:
In many ways the USB line has replaced the MIDI serial line for most of
todays MIDI work. I think this is a good thing as it means each MIDI unit
has it's own port. The one thing the MIDI port has is groundloop
protection, USB does not.
its own physical connection point, maybe. but USB interconnection is
heavily hub dependent. and each port doesn't get its own one of those.
groundloop protection for a serial data protocol?
6:17 p.m.
On Sat, 12 Jul 2014, Paul Davis wrote:
its own physical connection point, maybe. but USB
interconnection is heavily hub
dependent. and each port doesn't get its own one of those. groundloop protection
for a serial data protocol?
It would not effect the serial data, but audio may be present on the same
device, or another connected to it. I have a USB audio interface that
introduces hum to the monitor amp. I haven't had time to trouble shoot it
yet, but it does have balanced outputs and the monitor has balanced in, so
I may be able to just lift the interconnecting ground.
--
Len Ovens
www.ovenwerks.net
13 Jul
13 Jul
3:37 p.m.
Hi,
On Sat, 12 Jul 2014 09:17:02 -0700 (PDT)
Len Ovens <len(a)ovenwerks.net> wrote:
t would not effect the serial data, but audio may be
present on the same
device, or another connected to it. I have a USB audio interface that
introduces hum to the monitor amp.
A passive DI-box with ground-lift will to the trick. The problem here
is not the asymmetrical signal since the noise is not inducted to the
wire. It's that any computer introduces quite a lot of buzz and hiss to
the ground wire. You can easily hear when the cursor moves or when data
is read from hard-disc and so on.
Best, Dennis
10:50 a.m.
On Fri, 2014-07-11 at 19:01 -0400, Paul Davis wrote:
On Fri, Jul 11, 2014 at 6:39 PM, Len Ovens
<len(a)ovenwerks.net> wrote:
Just looking through the midi messages used by the Mackie and
other controlers. It appears to me that it is designed to be
used on it's own physical midi channel as it uses (up to) all
the logical midi channels (1 to 16) and so could not work
running through a midi kb for example.
MIDI Machine Control is even more demanding, although it is all sysex,
and MIDI Timecode has always been recommended to be delivered on its
own cable (if using serial MIDI at least).
For serious MIDI work there is always the need to have several
individual computer MIDI outputs. One output very seldom is enough. IOW
if you own several MIDI outs, you usually also own several MIDI ins. As
long as there are free PCI slots, it shouldn't be an issue. Envy24 cards
are cheap at Ebay (~ 30 €). Likely USB MIDI interface jitter doesn't
matter for mixer usage, so additional interfaces would be very cheap (~
10 €).
On Sat, 2014-07-12 at 07:34 -0700, Len Ovens wrote:
My last use of MTC/MCC was syncing a sequencer to
physical
tape.
To sync to physical tape I recommend to use SMPTE ;).
10:55 a.m.
On Sun, 2014-07-13 at 10:50 +0200, Ralf Mardorf wrote:
On Sat, 2014-07-12 at 07:34 -0700, Len Ovens wrote:
Sure, a pro/consumer tape recorder always is the SMPTE master and the
computer just is a MIDI sequencer without hard disk recording.
My last use of MTC/MCC was syncing a sequencer to
physical
tape.
To sync to physical tape I recommend to use SMPTE ;).
3:28 p.m.
On Sun, 13 Jul 2014, Ralf Mardorf wrote:
On Sun, 2014-07-13 at 10:50 +0200, Ralf Mardorf
wrote:
> On Sat, 2014-07-12 at 07:34 -0700, Len Ovens wrote:
>> My last use of MTC/MCC was syncing a sequencer to physical
>> tape.
>
> To sync to physical tape I recommend to use SMPTE ;).
Ya, the box put your chosen smpte on the tape and translated that to
bars/notes at b/m. A song could be loaded with sysex that had time sig.
and tempo changes... I never did, because I just recorded without using
the metronome and so was not on the notes anyway. That seemed to be what
worked best with the qx7 I used then.
Sure, a pro/consumer tape recorder always is the SMPTE
master and the
computer just is a MIDI sequencer without hard disk recording.
I had a mega2... so no real audio IF. A fostex R8 for which I can no
longer find tape locally. I missadjusted track 8 to record 10db down so
there was less crosstalk from the smpte track to audio.
--
Len Ovens
www.ovenwerks.net
4:07 p.m.
On Sun, 2014-07-13 at 06:27 -0700, Len Ovens wrote:
I missadjusted track 8 to record 10db down so
there was less crosstalk from the smpte track to audio.
AFAIK even a few drop-outs don't cause issues, I at least was able to
record the SMPTE track that low, that there wasn't audible crosstalk on
a Yamaha MT44D 4 track cassette recorder and using Dolby C also didn't
cause issues for the SMPTE code. It's wise to use the first or the last
track just in case there should be crosstalk and the track next to the
SMPTE track should be used to record loud audio signals, that need less
dynamic and that have less rests.
3569
days inactive
3571
days old
linux-audio-dev@lists.linuxaudio.org
9 comments
4 participants
participants (4)
-
Dennis Schulmeister -
Len Ovens -
Paul Davis -
Ralf Mardorf