>My only interest is in th interface components useful in making a device
>driver.
Sure. I was just curious as to whether there was scope at a later to date to
play with the DSP code.
I've looked at the source again (cheers, David ;) and I can see what David
means, in that for each device (Darla20, Darla24 etc) there is a block of
data defined eg in Darla20DSP.c (in the DSP folder) which is the microcode to
load into the DSP.
So we don't need to mess about with that at this stage, if ever- TBH the hex
doesn't look like code seqs to me (especially the Mia stuff) more like tables
of setup info. Still, as you say, it's irrelevant to what we're doing, which
is to interface that DSP to higher level functions.
Sorry if all this is obvious; hopefully writing up our understanding of what's
going on will help others.
Hello,
Sorry for the OT message but I thought those of you within the UK
might be interested. I am selling lots of Computer Music magazines on
Ebay. I will post to within the UK, and all the auctions start at just
10p (with no reserve), which is pretty good considering each magazine
comes with a CD containing loads of samples and software (and they cost me
5UKP each).
You can see the auctions (with photos and descriptions) at:
http://search.ebay.co.uk/search/search.dll?MfcISAPICommand=GetResult&ebayta…
Thanks for your time.
Cheers,
Bill.
--
Dr. William Bland. Computer Programmer, UK.
www.abstractnonsense.com
It appears to be some kind of latency optimisation for busses, but I can;t
really work out what it does. Theres a whitepaper about it here:
http://www.sis.com/hs_tech/
The claim is that it can reduce system latency by proritising certain
streams. I think. If you could express these priorities to the kernel it
might be of some use.
Anyone know more about it?
- Steve
I found it hilarious that the writer found that Linux is not viable
because none of the *big names* in audio software support it.
Doesn't matter about the companies that actually make the machines
though. Nooooooo sirrreee. It's the software manufacturers who we should
all be sucking up to.
However he is, he is definitely uber cool.
--
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.comHttp://www.djcj.org - The Linux Audio Users guide
========================================
Being on stage with the band in front of crowds shouting, "Get off! No!
We want normal music!", I think that was more like acting than anything
I've ever done.
Goldie, 8 Nov, 2002
The Scotsman
How about having all apps implement Open Sound Control (some of them already have, such as pd, csound etc.)?
Then you could control them all from one source (i.e. RTMix). Then, suddenly there would be no redundancy ;-)...
Ico
>
> From: Lukas Degener <AFBLukas(a)gmx.de>
> Date: 2003/03/18 Tue AM 08:54:55 EST
> To: linux-audio-dev(a)music.columbia.edu
> Subject: [linux-audio-dev] Modular synths of the world, unite and take over :-)
>
> Roman Kaljakin wrote:
>
> >I am pleased to announce Octavian - a realtime software synthesizer for GNU\Linux
> >operating system.
> > Octavians's design is like analog modular synthesizers,(...)
> >
> Well, here we have another modular synth framework. :-)
>
> Hi Roman, i realy like parts of your ui design. just looked at the
> screenshots so far, but i think i will try octavian soon.
> I would have reacted earlier to your announce, but i was somewhat busy
> and didn't follow lad traffic very regulary.
>
> Sseems we have a little problem.
> Ok, maybe problem is not exactly the right term, let's put it this way:
> Right now, there is beast, there is gAlan, there is ams, and of course
> there is also pd, jmax, etc. and lately Octavian, and, rats, there maybe
> a zillion of other apps out there that i do not yet know of (authors of
> such apps, please append your project to my list:-) )
>
> While each of this projects may have unique approaches to certain
> problems, or use different metaphors for similar things, i guess it is a
> valid assumption, that they all have _very_ similar goals in terms of
> functionality. At least that was my impression after talking with Stefan
> (beast) and Torben (gAlan).
>
> The Big Question(tm):
> How can we avoid redundant work?
>
> My (somewhat utopious) suggestion:
> maybe we should think in components that use/modify a common
> datastructure/model.
>
> This has almost (but not completly) nothing to do with merging ;-)
> It means that we have to agree on what exactly that common model would
> be, and after that, we would go on writing
> different components that actualy work with this model. The problem of
> course would be to define that model.
>
> But once we have managed this, it should be possible to have different
> components cooperate on the same instance of that model at the same
> time, without knowing about each other, i.e. all "inter-component"
> communication would be established via the model. I tend to think of
> this as a "Macro Model/View/Controller" pattern. (i have forgotten the
> actual term, something like "Document Oriented Design" i think.)
>
> So this goes out to Matthias, Torben, Stefan, Roman, and of course
> everyone else interested in such a thing:
> What do you think?
>
> Regards,
> Lukas
>
>
>
>
>
>
Hello linux-audio-dev-request(a)music.columbia.edu
I have received your e-mail regarding 'linux-audio-dev digest, Vol 1 #402 - 13 msgs' I will be out of the office until the 24th of March. Please refer any queries that require immediate attention to Phil Carroll @ philc(a)europlex.ie
Regards
Richard Caldwell
> with all due respect, you are talking about somewhere between 1-5000
> lines of code that would take someone experienced about 3 days to get
> to 60% functionality. once it reaches that point, ALSA will happily
> take it on, and you get CVS and the ALSA mailing lists to use.
Fair enough, I don't know enough about linux module coding. If we can get a
60% functional version in less than a week, I'd be dead chuffed! ;)
We're effectively talking about a driver for the Motorola DSP onboard (I can't
remember what the no is.) We first need to get it to C code- isn't that what
the CPP used to do?
Sorry, it's been a while. 8-)
Hi there,
Waldorf from Germany has made an analog VCF which
could be connected via USB to a computer system:
http://www.waldorf-music.com/afb/
Regards,
Joachim Backhaus
> -----Original Message-----
> From: Thomas Webb [mailto:magusofthedark@yahoo.com]
> Sent: Mittwoch, 19. März 2003 14:52
> To: linux-audio-dev(a)music.columbia.edu
> Subject: Re: [linux-audio-dev] Interface with real modules
>
>
> > However you can still have a lot of fun e.g. having
> > FM or Ringmod between
> > software and true analogue VCOs. It would also be a
> > very good idea to
> > combine a true analogue VCF with a digital synth as
> > it's the filter that
> > is the weakest point of digital synthesis. It is
> > then however difficult to
> > implement proper VCF tracking. This could only be
> > done by using a true
> > analogue MIDI to CV converter, let this control the
> > VCF tracking and send
> > the same notes to the softsynth and the true
> > analogue MCV connected to the
> > VCF.
> yeah, the main thing I was thinking of was using an
> analogue filter.. The medical company I work for has
> this real hightech voltmeter (high res and
> everything). I can probably get that to work
> perfectly with any modules. The only problem is it's
> freaky expensive. Too bad a standard soundcard won't
> work quite right.
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
> http://platinum.yahoo.com
>