On Sun, 2010-07-04 at 21:52 +0100, Dan Mills wrote:
> Trying again, I accidentally sent this off list the first time....
So I can add, I anyway will test to use two PCI cards, at least for
MIDI, for audio would be nice too.
-------- Forwarded Message --------
From: Ralf Mardorf
To: Dan Mills
Subject: Re: [LAD] No nagging, a serious question
Date: Sun, 04 Jul 2010 22:47:47 +0200
It was off-list?!
On Sun, 2010-07-04 at 21:35 +0100, Dan Mills wrote:
> If you are working in a world where you know the available hardware in
> detail LOTS of things become easy, for example I can time stamp an
> incoming MIDI byte with the sample number of reported as current
> position by the sound card (There is only one), instant way to get
> effectively zero latency jitter.
> This doesn't work nearly so well when there is more then one sound card
Good to read about this issue. I always disable the on-board audio
devices, but I would add a second PCI card to my PC and sync it with the
already installed sound card, so I better don't do it. It at least would
be nice to have several MIDI IO by simply using some cheap Envy24 cards.
Unfortunately those cheap cards seems to use just one of the two MPUs
supported by the Envy24.
Cheers!
Ralf
Greetings,
Martin Eastwood has posted the code for his MVerb:
http://martineastwood.com/
Open-source, GPL3'd free software.
Maybe someone could whip up a plugin or standalone app from this code ?
PS: If you download the zipfile note that it does not include a
top-level directory, i.e. it'll dump its contents into the current
directory.
Best,
dp
On Mon, Jul 19, 2010 at 8:06 PM, Bernardo Barros
<bernardobarros2(a)gmail.com>wrote:
> At least for me it would be easier to think as c = 0
>
> c = 0
> c' = 12
> c, = -12
> c'' = 24
> c,, = -24
>
> because most of the notes in a regular score is mostly like to happen
> in the middle and things looks simpler that way. UNLESS you're already
> familiar with all kind of notes with MIDI number notation.
>
Hey,
Yes I was referring to the MIDI standard there.. Should have mentioned
that..
There's no "rule" telling you you should do it differently, I'm expressing
my opinion that
for me it would seem more logical to have middle C at 60.
-Harry
On Monday 19 July 2010 15:13:54 Bernardo Barros wrote:
> Yes, but a lot of stuff is not presently appealing to industry.
> Like... ,music and multimedia stuff: LilyPond, SoundCard drivers,
> InkScape, GIMP, Ardour, Qtractor and so on. But yes, even though I'm a
> socialist I agree with you that big corporations would benefit with
> Free Software a lot.
I wouldn't be too sure about that. You might just need to think of which
industry. And A lot of the groups I mentioned are normally small businesses
around here. There are a decent number of one man operations wrt
loclsmithing. Barber shops go from one barber to several but they are not big
corporations by any means. The associations may be bigger, but if the members
wanted the software written for them to be Free, they could use their
association to coordinate their efforts.
>
> 2010/7/19 drew Roberts <zotz(a)100jamz.com>:
> > On Monday 19 July 2010 12:12:54 you wrote:
> >> Maybe they always overlap somehow, software needs support. Really good
> >> and complex software need more support than one person can do just
> >> with his free time. I am not sure from where this support could come
> >> from.
> >
> > I keep thinking that industry groups would be wise to support the
> > development of Free software for their industries.
> >
> > For instance:
> >
> > Locksmiths
> > http://www.aloa.org/
> > http://www.uklocksmithsassociation.co.uk/
> > http://www.masterlocksmiths.com.au/home.aspx
> >
> > Barbers, Beauty Salons, Furniture Stores, Ocean Engineers, Corner Grocery
> > Stores, what have you.
> >
> > all the best,
> >
> > drew
> >
> >> From universities, donations, companies, governments? The Linux
> >> kernel, for example, is very complex and needs a lot of work all the
> >> time since new hardware and software need it , and it is well
> >> supported by really big companies like google, novell and red har.
> >> Other areas this is not so easy to get support from companies, so I
> >> now just can think of the other options: donations from people that
> >> make money or work seriouly with the software, universities and
> >> government programmes. The last one seems unlikely to happen but here
> >> in Brazil the present government is officially supporting Linux and
> >> some software projects. Donations from professionals and Universities
> >> can help Free Software a lot too.
> >>
> >>
> >> 2010/7/19 drew Roberts <zotz(a)100jamz.com>
> >>
> >> > On Sunday 18 July 2010 11:36:42 you wrote:
> >> > > On Sun, Jul 18, 2010 at 10:04 AM, drew Roberts <zotz(a)100jamz.com>
wrote:
> >> > > > Commercial and Free are not opposites.
> >> > >
> >> > > no, just siblings who fight with each other like crazy for 18 years
> >> > > before developing a deep and abiding love for each other :)
> >> >
> >> > Free and Commercial can intersect / overlap. Venn wise.
> >
> > _______________________________________________
> > Linux-audio-user mailing list
> > Linux-audio-user(a)lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-user
On July 18, 2010 03:57:06 pm Ralf Mardorf wrote:
> A lot of kids wish to have a kill switch for their guitars.
> A kill switch is a short circuit, to 'stop' the audio signal.
>
> I'm not fine with this solution, but the kids argue, that e.g. an
> interruption does cause unwanted noise, especially for over drive
> sounds. IMO even using opto-electronics won't solve the issue, because
> the noise of the transistor overdrive effect still would be hearable,
> while for a short circuit there is silence.
>
> Has anybody an idea to solve this without a short circuit?
>
> I'm really not a fan of short circuits. Note, it's not possible to do an
> interrupt all the times behind the latest noise generator and even an
> interrupt could cause noise itself, while a short circuit indeed is a
> good way to cancel sound.
If you don't like short circuiting the mics, just switch the output jack
hot lead between ground and the volume pot(s).
Connecting the output to ground is the same as turning the volume down.
There is no need to short the mics...
On 19.07.2010 08:30, Tim E. Real wrote:
> If you play a Gibson you can set the neck pickup volume to zero and
> the bridge pickup volume to full and then toggle the pickup switch,
> rapidly if desired, like Eddie van Halen on You Really Got Me.
> Tim.
Tom Morello gets real creative with his guirar, and uses this technique
alot. He also unplugs his guitar to make the pedals and amps make noise
(oscillate), and controls the noise with his wah pedal and by touching
the tip of the plug to the guitar bridge (which is grounded). Good
demonstration of how just cutting the signal lead can cause lots of
noise, while a short will be more or less silent :)
-Sakari-
Hi all,
I've just released a beta of a modular synthesis library using Jack2,
with a Ruby module. See http://ebuswell.github.com/Cshellsynth/
There's no mailing list for the project yet, but feel free to email me
directly if you have questions/comments/concerns.
Enjoy!
Evan
Hello all,
Early this week one of the three 'rendering' PCs of the WFS
system in the Sala Bianca failed. It just appeared completely
dead and didn't even try to boot when the power button was
pressed, but the standby power (for the network interface)
was available.
I suspected the power supply, so ordered a new one which
arrived two days ago. Installed it and things worked again.
But now comes the interesting part. While installing the new
PS, I also disconnected the wires to the power button, and
to test I just used a screwdriver to short the two pins that
normally connect to it. But when I reconnected the power button
the PC switched off after a few seconds. So it seemed as if the
power button was permanently being pressed. I again installed
the old PS, and things worked as long as the power button was
not connected.
Measuring the power button switch with a multimeter showed
an unstable resistance value of between 1 and 3k while it
was not pressed. So I removed the thing, which turned out
to be a cheap miniature switch, a little cube of around 8
mm size. I opened and disassembled it, and noticed that the
contacts had some black dirt on them. Cleaned with aceton
and reassembled, and things worked perfectly again.
What I don't understand is how the contacts got so dirty.
If a resistance of a few kOhm is enough to make it look
as a closed contact then it can't be handling large currents,
so there should not be any arcing. And the construction of
the thing is such that it is virtually closed, no dust or
whatever could ever creep in.
Still it's quite sobering that this cheap 0.30 Euro thing
was capable of bringing down a 1600 Euro workstation...
Who would suspect a switch to fail in this way ?
Ciao,
--
Je veux que la mort me trouve plantant mes choux, mais
nonchalant d’elle, et encore plus de mon jardin imparfait.
(Michel de Montaigne)
The following job offer for a C++ developer may be of interest to you or
some one you know.
==== About GRAME ====
Based in Lyon (France), GRAME, Centre National de Création Musicale
(national center for musical creation) is a leading music institution
dedicated to contemporary music and digital arts. Its activities range
from artistic to scientific. GRAME's research department is involved in
various French and European research projects as well as in several open
source projects (Faust, Jackdmp, MidiShare, libMusicXML, GuidoLib, etc.)
Grame's home page: http://www.grame.fr
==== Job Description ====
GRAME is looking for two C++ developers willing to collaborate together
with its research team in the development of the future version of FAUST.
FAUST (Functional Audio Stream) is a functional programming language
specifically designed for high level real-time signal processing and
synthesis. FAUST targets high-performance signal processing applications
and audio plug-ins for a variety of platforms and standards. Its
compiler translates Faust programs into equivalent C++ programs taking
care of generating the most efficient code. Thanks to advanced
compilation techniques, the resulting code can generally compete with,
and sometimes even outperform, C++ code written by seasoned programmers.
The future version of FAUST will introduce several new and exciting
features, especially the support for multirate and multidimension
processing. This will open a whole range of real time applications,
from spectral to video processing.
The recruited developers will be hired on a full-time limited-term
contract of 6 months, from October 1st, 2010 to March 31, 2011.
FAUST's home page: http://faust.grame.fr
==== Profile ====
* Excellent C++ programming skills :
- methodical work,
- clear programming and documentation style,
- high productivity
- good at understanding and modifying existing code
* Strong Computer Science background :
- compiler technologies
- Lambda-calculus and functional programming
- type systems and type inference,
- code synthesis
* Good Knowledge of audio/video processing techniques and
associated Maths.
* Familiarity with Linux and GNU Tools
==== How to apply ====
To apply, please send an email to orlarey at grame.fr mentioning "job
offer at Grame" in the subject and adding :
* A brief presentation letter stating your interest in the offer.
* Your resume
* Optionally, code samples and pointers to open source projects you
have contributed to
Yann Orlarey
Scientific Director
GRAME
9 rue du Garet
BP 1185
69202 Lyon Cedex 01
France
Without running JACK and with running JACK -p2048 44.1Khz and 96KHz,
without HR timer enabled and with HR timer enabled ALSA MIDI used to
make a thru connection was always ok when playing live, not only for the
PCI MIDI, but even for USB MIDI.
When playing the recordings from my last test by Qtractor, there wasn't
the issue anymore that FluidSynth and the internal Linux recorded
FluidSynth sometimes were out of sync. The MIDI and the audio track were
always in sync. I only tested it with system timer.
Anyway, there definitive is jitter for the recorded FluidSynth. It's
inaudible jitter, resp. it is audible when loop playing, because some
beats are played to early, because of jitter with negative delay. So
it's not an issue of bad timing, but because of notes that shouldn't be
played, when loop playing. It's still a recording from the last test,
not from today (note, I'm not writing about the hw MIDI at the moment).
There must have been something bad, that is ok today. I wondered myself,
because I never had this issues before.
I didn't test MIDI jitter for hw MIDI today. Anyway, ALSA MIDI for MIDI
thru is ok and also Qtractor always plays the MIDI and audio track in
sync.
For the important jitter tests I'll switch back to 64 Studio 3.0-beta3,
there might be something broken for 64 Studio 3.3 alpha or it was just
bad luck, anyway at least for FluidSynth with 3.0-beta3 there never were
issues.
Over the weekend I had no time to test MIDI as it was planned. It likely
will be the same for the next days.
Again there's hope that PCI MIDI jitter will be inaudible. Because even
the USB MIDI was ok for live playing, I suspect that the jitter for the
recordings is not regarding to ALSA MIDI. I wish I would have the time
to do some recordings right now.
Hi,
AFAIK Lennart and some other Red Hat devs, where talking about the Linux
Plumbers Conference at LAC2010, telling why it would be good if people from
the linuxaudio world would join that conference and why it could improve the
state of linuxaudio in the Linux environment.
Here is a call for papers:
http://www.linuxplumbersconf.org/2010/06/03/linux-plumbers-conference-call-…
\r
