On Monday 18 December 2006 07:02 pm, Brian Dunn wrote:
> Message: 1
> Date: Mon, 18 Dec 2006 19:40:20 -0600
> From: Brian Dunn <job17and9(a)sbcglobal.net>
> Subject: [linux-audio-user] jack-rack svn won't lash
> To: A list for linux audio users <linux-audio-user(a)music.columbia.edu>
> Message-ID: <45874304.1010605(a)sbcglobal.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I've compiled the svn version of jack-rack 1.4.5rc3, because the 1.4.4
> version is not connecting to my lash server. I've compiled the svn with
> ./configure --enable-lash, and, alas... still no lash entry is generated
> when the program is started. Has anyone had any luck with jack-rack and
> lash? I've tried to RTM... but I can't find any info on lash usage there
> or in the web site.
I used 1.4.4 patched with 'jack-rack-lash-shutdown2.diff' and that worked.
1.4.3,1.4.4 and 1.4.5rc2(sic) alone wouldn't be lashd.
Alot of this is due to grounding methods. Interestingly, a test recently
conducted showed that having a ground (one that literally went into the
ground) horrendously increased rf interference. They began to look at why,
and saw that most of the pro audio devices had a grounding method that was
inadequate - mics being grounded to the shielding as they should, but also
jumped across the circuit boards - this being the main source of issue.
I forget who did the study, but there is a whitepaper out there. I don't have
it at home, but I do have it at work - I will be back there tomorrow (home
sick) and will post up a link to it then. Lots of info is packed in there.
As a note, the one interesting thing that came from this was a line of mics
that were "blackberry-proof". I'll have to remember who made those, it may
be of interest as well.
-Joseph M. Gaffney
greetings!
following up on my recent (unanswered) question about a timecode
generator, i am now interested also in software capable of parsing a
SMPTE timecode stream (audio, NOT MTC), and displaying the
corresponding numerical timecode, as the audio track is running.
an ideal solution would be one implemented as either a ladspa plugin,
which can be patched into the track (i.e. in ardour) containing the
timecode, or a small jack utility which can be connected to either
incoming SMPTE signal or a playback track via i.e. the qjackctl connect
window. i would like to be able to run multiple instances of such
software, to compare timecode in various audio streams.
do any of you know of the existence of any such software? alternately,
does anyone out there have the ability to program such a thing? i would
be willing to donate to such a cause. perhaps other are looking for
this sort of thing as well? it would surely be a big step forward in
our ability to work with film and video -- those folks can't deal with
MTC.
.pltk.
On 12/18/2006 07:03:31 PM, Robin Gareus wrote:
> plutek wrote:
>
> > following up on my recent (unanswered) question
>
> I was waiting with interest for replies, too!
>
> > i am now interested also in software capable of parsing a SMPTE
> > timecode stream (audio, NOT MTC), and displaying the corresponding
> > numerical timecode, as the audio track is running.
>
> you mean LTC: http://en.wikipedia.org/wiki/Linear_timecode ?!
> I don't think there is open source software to parse LTC just yet.
> There are a few emails and discussions out there (eg. LAD July 2000).
yes, LTC.
yes, i've read the discussions.
(yes, they're old!)
>
> > i would like to be able to run multiple instances of such
> > software, to compare timecode in various audio streams.
>
> I suggest to have a single jack application with <N> audio
> input-channels: a standalone application can easily do some maths,
> eg. display differences between SMPTE's. or record some tracks to
> disk.
yes... good suggestion, of course.
>
> I was interested in having a tool that reads the first [LTC]SMPTE from
> a
> [analog] recording and use it as offset for the recorded [digital]
> file.
> At the end I would only be interested in the drift+jitter information
> (no varispeed). There's also "video sync to external LTC audio" on the
> xjadeo ToDo list (with varispeed), but I lost interest as all recent
> recordings I get are made completely digital.. no need for analog sync
> tracks! I do not even have analog recording hardware any more :-(
cool to hear it is (or was) on the xjadeo todo list, although once
we're dealing with digitized video in xjadeo we don't, as you point
out, really need ltc any more. i've needed this stuff recently while
doing audio for live video shoots, just so we can all work from (and
record) a common timecode reference, and confirm while shooting that we
are actually locked.
>
> > alternately, does anyone out there have the ability to program such
> a thing?
>
> could be done. the specs seem to be open, although there might be some
> patent issues for commercial users.
>
> it should become a library to read/write LTC SMPTE.
> Let's see if the ardour or alsa guys can dig out some old code, but
> else
> I'll get started on a framework in the upcoming dark evenings of my
> ski-trip: It's not really hard to detect phase transitions and decode
> the signal, but I need to rely on you (or others) for testing.
i'd be happy to test.
>
> Do you have hardware that can read or generate timecode, or just
> files?
yes, i can generate, but i cannot parse an incoming stream. i also have
no way of knowing what time i'm spitting out (unless i also send MTC
and lock i.e. ardour to it), since my generator (an old opcode
studio64-xtc) just runs with no display of where it is. it CAN lock to
incoming LTC, but again i must tell it to transcode to MTC and then
lock software to it in order to know what's going on. i suppose that's
not a big deal, except that the software which is necessary to set up
reading and writing MTC only runs on windows, so i would need to dig up
an old win95 machine and use that to set the user modes on the
studio64, then take the box and run with it. (ick, i feel so DIRTY...)
maybe it's time to go hunting for that studio64 floppy....yikes.
>
> I'd guess that it can get somewhat tricky with noise, variable speed
> and
> funny framerates... but the simple part should take less than a few
> days. and maybe others in the community can help out on the
> "professional touch" once there is some code to get started with.
robin... it would be awesome to be able to deal with incoming/outgoing
LTC directly. i'm hoping there are some other interested souls who
might crawl out of the woodwork here, if this gets off the ground.
linux should get into the video/film shoots, and it needs LTC to do
that. windows and mac can both deal with LTC directly.
.pltk.
Ok, last question this morning. ;)
Subjective opinions on which linux time/pitch shifting utility is the
most usable for changing keys and tempo of music ( no voices )? Does not
need to be "production quality" but good enough to shift backing tracks
and still be able to use them. Able to run on OSX as well under fink
would be a bonus!
Thanks
Iain
I have a couple of questions re lilypond before trying it out if anyone
can help me.
- Can I force formatting and spacing such that there will *always* be 4
or 8 measures per print line?
- Can one change the type setting and format of the English chord
symbols? ( ie how one notates say C7+9 etc )
- Is it fairly easy to integrate lilypond with databases?
Thanks
Iain
Hello, all -
I am a brand-new member to this list. I want to thank you all right off
the bat for providing this list.
I am in the process of putting together a personal music production
studio. I am a former professional musician who changed careers to
computers a number of years back and I would like to get back into
music and digital recording as a sideline/hobby.
I need some recommendations as to which components to use in a
Linux-based DAW.
I have a Delta 1010 on the way, and would like recommendations on parts
(motherboard / CPU / memory / drives / distro) that would make a
machine that I would not have to wish later on that I had bought
something else. My main use for the system would be recording my Brass
Quintet and my piano/keyboard musings (the hobby part) and possibly
live recoding work (the sideline part). Seems to me that there would be
some money to be made by recording events and providing Cd's for sale
immediately after, as well as MP3's online.
Forgive me if this information is in the archives somewhere. I looked,
and could not find something that recommended all components of a
complete system. If this info is already on the net somewhere, please
point me the way.
Also - where I work, we are heavy into iSCSI storage area networks. Has
anybody ever used one of these (like maybe, openfiler) for the storage
of music data?
Thanks again so much,
Mark in Michigan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello!
I?ve decided to rely on a commercial product for symphonic sampling and
my choice is MOTU?s Symphonic Instrument.
Has anyone tried it out under Linux? Will it work together with jackvst,
dssi-vst or wine?
Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFhr/VuXdsp50C0vMRCEuTAJ4iFPq7UACdcLHE9CFOaVJtruaSiACgjudq
MTouYQQlrRliN/Kp6ntx+68=
=h2au
-----END PGP SIGNATURE-----
Ever read that FCC certification on the back of your machine? Its interference
to the outside world is below certain limits and it must accept all
interference from the outside. Thanks a bunch.
Things have come a long way. The DEC micro-computer I once worked at home on
blacked out TV over a nice radius. I thought I was doing the world a service
but awaited neighbors' complaints which thankfully never came.
How about having a session ruined because someone is nearby with their
cellular phone? I am not talking about their voice. Outgoing and incoming
calls transmit a nice signature through the audio system, in the computer or
external amps, etc. Every time. (Most of this equipment was designed/built
before the overabundance of these toys.)
I assume the computer stuff is grounded. A little battery guitar amp might not
be. No matter, both get the calls. Had to kill the PA last night because the
organizer would not kill his phone.
What can one do about it?
It seems that the qjackctl patchbay only works with clients as a whole -
you cannot selectively connect individual ports within a client. I'd
just like to verify that this is really true.
If the connections in the "Connections" dialog were saved as a
configuration file, that would help, but I think that this is not the case.
The reason for this question is that it seems that pd cannot generate
multiple jack clients, and I want to route more than one qsynth engine
into it.
In the meantime, I am setting up scripts that use jack_connect and
aconnect, but this is a bit tedious. I'm using DeMuDi 1.2 (I don't know
why I waited so long to try it!)
So, if anyone has suggestions or clarifications, I'd be very grateful.
Thanks as always to the list members for their unfailing help and
suggestions.
Larry