me, but I need to do some cleanup, and do a
stereo version. I'm also thinking of a modified version to handle
the situation where I'm outputting audio to my 5.1 Home Theatre
system.
I had named it 'PrioMux' (Priority Multiplexer), but if the correct
term is 'Auto Mixer', then I can easily change it before release.
Best Regards
Iain
source below. It's really been ripped
off of the example amp in the LADSPA SDK I'm afraid
Thanks in advance for any help, this last bit is driving me mad, now
I've worked out how to code plugins!
All the Best
Iain
/* priomux.c */
/* Written by Iain Young, [EMAIL PROTECTED]
I would
hate to do any lower level programming in it.
Iain
I'm planning on some trying out some voice and pitch recognition stuff
for some ear training utilities. Wondering if anyone can tell me which
of the many FOSS libraries for both would be best. Cross platform a
bonus, but not essential.
Thanks
Iain
sequencer, but I am definitely more of a designer
then experieced coder, so it would be great to collaborate. if there is
interest I can start a list and site for this. Feel free to contact me
here or off list.
Thanks
Iain
aking from a selfish viewpoint ... I'd like it if you made another
one with built in limiting and/or safety control. =)
Iain
ifications on the development pages in
the upcoming days.
Will that be 2.6.12 patched with Ingo's RT patch? Seems to be giving me
very good real time performance right now even with only the desktop
preemption level.
Thanks
Iain
I use ecasound whenver I'm going to do the same batch of things to a
bunch of recordings. I'll be using for a quick&dirty
restoration/remastering contract next month.
'Course I'm really only semi-pro. Some months I'm pro, some months I'm
not. ( Right now it&
Aha, thanks Lee and Paul, that explains that!
Iain.
Lee Revell wrote:
On Wed, 2005-07-13 at 12:12 -0700, Iain Duncan wrote:
In realtime critical applications people prefer RTLinux or the RTAI extension
to the kernel for periods and scheduling latencies in the low microseconds
range (<
nt already http://devel.dynebolic.org
Is it at a point where one could customize a dyne:bolic using glibc2.3?
I seem to recall seeing on your site that the new one was a newer glibc
right?
Thanks
Iain
sorts of kernels
inappropriate for audio? ( Just out of curiousity. )
Thanks
Iain
ument. Please chime in if you care about this.
I would be happy to do so. I'm not familiar with LKML, how would you
suggest I do so? Is it appropriate to subscribe just to place my vote on
that issue?
Thanks
Iain
accurately.
Thanks
Iain
r am
or really high freq stuff, and knob/slider tweaks certainly don't!
Iain
Artemio wrote:
Hello all!
Okay, I now understand the situation but I really think there should
be some development in this area. Interpolation is fine but only for
linear modulation as you guess, and knob/sli
we're available!
A massive thanks to all you hard working developers who have made this
possible!
Iain
http://www.xornot.com
[EMAIL PROTECTED]
Erik de Castro Lopo wrote:
Hi all,
As some of you may know Linux.conf.au is on in Canberra, Australia
at the moment and that today we had an audio mi
I should have mentioned that I'm certainly interested in any other
non-agnula live cd solutions as well.
Thanks
Iain
and being happy with all major sound and
midi cards, etc.
Any thoughts, pointers, etc?
Thanks
Iain
Why do you want letters from project maintainers only? Don't you want
user letters as well?
Iain
Jean-Marc Valin wrote:
If someone sets up this forum, and more than twice of us sign
up, that should show those arrogant lklm-people that there are really
_a lot_ of us, and that we are strong
hese by accident easily.
Link it from all the pages that a new user would go to while learning
how to do audio on linux.
I don't really know what to say and who to say it to. But if someone
tells me, I'll do it, and I'll tell every linux interested musician I
know to do it to so
adds
weight to your request, I suspect a lot of people would be happy to
oblige, and I have a hard time believing it wouldn't have an effect. I
mean who doesn't want their work to be the world's best platform for
something?
Thanks
Iain
going.
Iain
er than to the normal 16th or whatever.
That was one sequencer's implementation of the term, but certainly not a
universally accepted strict definition.
Iain
I seem to remember having some floppys of grooves back in the atari days
and doing this with midi shaker patterns and the like, but it
So essentially what you're saying is "MIDI groove" isn't really a
well-defined thing, just a catch-all phrase for humanization/groove
techniques in sequencers and whatnot.
yes.
does a good job of making real time use the
first priority, which is also what I want. If you think I should look at
other code for learning real time timing critical programming for a live
sequencer, can anyoune suggest a good project to look at?
Thanks
Iain
ay to learn the kind of
programming I want to do, and I'd like to know what I should make sure I
bone up on first.
And it uses pthreads right?
Thanks
Iain
nable both. Or even
enable midi messages based on audio analysis.
Iain
e trick to making the
waveform visualiztion interesting is to allow the user to break up the
composite waveform into user defined frequency bins so you can ride
the amplitude of specific frequency areas.
Iain
But you have lots of continuous controllers, is it 31?, and they control
16 channels
e trick to making the waveform visualiztion
interesting is to allow the user to break up the composite waveform into
user defined frequency bins so you can ride the amplitude of specific
frequency areas.
Iain
a MIDI patch bay with extreme features (MIDI data filtering,
rechannelization, event mapping, etc)
Something like the above with a Snd style scripting language would be
hella cool.
Iain
The beginnings to some of these things are already available, so you'd
have a leg up on getting st
kages for various kinds of customization including
specifically for multi-media with the low latency and pre-emp patches
applied already.
Iain
lutions that perhaps have been improved upon with recent linux
threading advances.
Thanks so much
Iain
However, this does not mean that I don't think other approaches will make
wicked audio software. We are always stuck choosing between expense and
features, and many choices are valid. In my live Csound rig I cut corners
for fast response all the time. But it ain't no modular . . .
Iain
27;s what a
modular synth is! They aren't easy to patch or easy to use!
Iain
s this been done already for other apps? For example, my csound
instruments are ridiculously complicated and would involve hundreds of
jacks, I would hate to try to program them with a gui. But with Vim and
Python helping me a long, patching in text is not so bad . . .
Just a thought!
Iain
having my CPU choke on a killer
modular than being able to run yet another limited software synthesize, know
what I mean? Modulars are supposed to be expensive . . . ; )
Iain
> On Thu, Jan 15, 2004 at 02:53:18PM -0800, Iain Duncan wrote:
> > I think the way to make an inter app modular really useful and new would
be
> > to use Jack for *ALL* signal passing including control signals as CV
> > emulations by passing a DC signal through Jack ( as s
nly one or two
things really well, and one could freely mix oscillators, filters, and other
processors to make complex patches.
Iain
was some sort of framework for interconnecting apps and plugins
controlled by midi and Jack DC signals, one could actually accomplish the
kind of flexibility possible with hardware modulars and still be able to
incorporate other work.
Iain
- Original Message -
From: "Mike Rawes&quo
This is the best: http://www.ucapps.de
If you want other links just ask on his forum.
Iain
- Original Message -
From: "Adam King" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 19, 2003 7:51 PM
Subject: [linux-audio-dev] Introduction to bui
going to make it much more difficult to
sort out priorities given that Csound kinda has to be allowed to keep
running. I figure it would be second highest priority after the engine
Thanks,
Iain
ode to include any GUI headers or
> reference any GUI objects. never. under any circumstances. jMax goes
Ok, that's good news. That's how my project has been designed anyway. The
engine is seperate from the user interface, which is in turn seperate from
the GUI. Thanks for your help.
Iain
't had to worry about any low
level stuff yet. But I would like to start modularizing it and making it
available to other people and platforms. It works well in Csound, but file
i/o is kluderific so I'd like to get that kind of stuff going in C as well.
Thanks,
Iain
ned about is the engine of the
sequencer outputing midi notes and csound events via pipes.
I was also planning on keeping it in just C so I could port it to
microcontrollers like the Microchip 18F series.
Thanks
Iain
> jackit.sf.net is your friend. forget about learning threading,
> scheduling iss
code to look at
would be much appreciated.
Thanks,
Iain
pen source
projects ) who is extremely experienced with pretty much all the controllers
out there built the midi box with the new system on Ucapps and thinks it's
best option period.
Iain
- Original Message -
From: "Fred Gleason" <[EMAIL PROTECTED]>
To: <[E
e graphic view of the data is clear as a block of solid colour in most
viewers.
I am interested to hear any and all feedback of course.
Thanks,
Iain Duncan
cord source etc), and finally to be
able to control the channels, change the level, change if it's the
current record source.
Is there a library that can do this all available anywhere, or will I
have to write it myself? Would it be a useful thing to have in a
library?
iain
--
"The '
under
the GPL.
iain
--
To live life is to be a hypocrite.
do? (is there a discussion of this
> somewhere?)
I think what bugs them [the GTK developers, and me as a user] most is
that they turn off all the window decorations and try to do window
manager functions (such as window movement, shading, docking etc) by
themselves, and invaribly get it all wron
port for audio-related tasks.
Of course there's (nearly) always time to make opinions on suggested widgets
;-)))
ciao,
Iain.
;-)
> I am not able to reconstruct this behaviour in a shell environment
> directly!
Interesting...
Iain.
in a handler and issue the
SNDCTL_DSP_POST/RESET in that ... otherwise the app will (probably) sleep on
the output queue until it is empty.
You should be able to see that with 'ps' if it's taking 2 seconds.
ciao,
Iain
til it was finished).
You could try issuing a SNDCTL_DSP_POST (which tells the driver you're
through with sending audio) - or, if that fails, a SNDCTL_DSP_RESET.
If that doesn't work ... then maybe you could look at the driver and see if
there's something missing from the OSS implementation.
ciao,
Iain.
> I still like "JACK", "API" and "LAAGA". "ALBA" is not bad but I agree
> that its a bit to close to ALSA for comfortable distinction between
> the two (should that be necessary).
drinking LAAGA until ALBA makes JACK 'API ... eh?
my vote is for "Jack".
Iain.
aving to learn
common things once.
---
failing this (probably tall order) ... at least we could try something like
it for LAD.
Yeah, I know, "show us the code"
well, I'll have to pass on that for now ... driver maintenance is already
backed-up to the middle of beyond :-(
ciao,
Iain.
at way no-one has to be 'right' or 'wrong' about key sequences (or whether
one-button mice are usable) etc. but, at the same time, the benefit of
similarity between app's common functions is maintained.
ciao,
Iain.
Yo Steve ... it *is* hot isn't it?
On Fri, Jul 27, 2001, Steve Harris wrote:
> On Fri, Jul 27, 2001 at 07:29:00PM +0100, Iain Sandoe wrote:
>> Why don't I like the -{x,c,v} keys on Linux & M$ - is it because they
>> are 'different' from the -{x,c,v} on Ma
On Fri, Jul 27, 2001, Steve Harris wrote:
> On Fri, Jul 27, 2001 at 02:08:12PM +0100, Iain Sandoe wrote:
>> order. [Iain rates the probability approx. = 0.5 * sqrt(bugger all) ]
>
> Possibly a bit of a high estimate ;)
>
>> an Audio HIG?
>
> I would be nice, bu
ssive. The link is:
>
> http://mambo.peabody.jhu.edu/~karlmac/publications/latency-icmc2001.pdf
guess which was the 'best'...
now I haven't actually read *all* the details ... it doesn't look like the
load tests are as severe as Benno's ... but I'm not sure.
Iain.
ssive. The link is:
>
> http://mambo.peabody.jhu.edu/~karlmac/publications/latency-icmc2001.pdf
guess which was the 'best'...
now I haven't actually read *all* the details ...
Iain.
> JACK - Jack Audio Connection Kit.
>
> Just wait till version 6.35 :-)
and thus Jack the LAD
sorry - it *is* hot in the UK (as Steve says it gets to us) ...
;-))))
Iain.
s "drop from great height" - is, I
suspect, that these learned keys, policies & so on are different.
---
Now, of course, in an anarchy, getting agreement about a HIG seems a tall
order. [Iain rates the probability approx. = 0.5 * sqrt(bugger all) ]
What about it LAD?
an Audio HIG?
o the job
without wading through fifteen layers of hierarchical menus - or resorting
to the manual - which as we all know is the "last resort for any engineer".
this all IMHO, of course...
Iain.
> POSA
> Paul's Own Sound Architecture
now *that* made me laugh ...
x27;d gravitate towards something that, at least, hinted what it *did*.
sort of AudioLink, SoundLink
... or the "XPatch" posted earlier...
ciao,
Iain.
Hi,
Has anyone got working any USB input or output *audio* devices?
How do they appear in the system? (e.g. /dev/???)
What audio API do they currently export? (e.g. OSS, ALSA??)
(I know this is not ALSA-dev - but to avoid cross-posting) How would they
appear under ALSA?
ciao,
Iain.
some of the time of course - but it will *never* be guaranteed.
The drivers & network stack are perfectly at liberty to drop packet
fragments that have been successfully received - for example, if there are
no mbufs available. I have seen network stacks (not looked at the linux
ones, I admit) that regularly do this.
If you want to network low-latency audio I think you must find a network
solution with a reliable physical layer.
my 0.02 euro ;-)
Iain.
67 matches
Mail list logo
