Re: [linux-audio-dev] Programming resource question

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Programming resource question
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Thu Nov 13 2003 - 08:24:27 EET


>Thanks Paul, Softwerk was already on my list of apps to look at it too. = )
>Are you still working on that at all or is it taking a back seat to Ardour
>and Jack right not?

its on the backburner, but the only things to do with it all concern
the GUI. oh, except adding "song support". the thing is totally
functional.

                     Also, did you make playback timing the top priority in
>Softwerk? For example, while limited in scope, Propellorheads did a great
>job with Rebirth of making sure that it acted like a 303 or 909; no matter
>how much you hit the buttons or twisted the knobs, playback is always even.

softwerk is totally designed like this. you get it for free by using
an MVC programming design. (almost) nothing that happens in the GUI
can stall the engine. softwerk itself likes to use the RTC for timing
purposes. running the engine thread SCHED_FIFO is also a key
ingredient of this.

>The thing I'm working on is meant for live gigs, so for example I want to
>make sure that if I execute a copy command, playback is fine even if the
>copy command takes a little longer to execute and forces the next input to
>wait a bit. I don't know enough C to know where to look in an app for that
>kind of business. Any other suggestions anyone? Any good books introducing
>this kind of thing? I'd like to find a bridge between basic C books and code
>and reading code of fully featured complex apps.

i haven't read any books on MVC per se, although they exist. "design
patterns" (gamma et al.) is always a good place to start (though it
assumes an OOP orientation, to some extent). the simplest way to do
MVC is to partition your app into an engine and a GUI with a defined
communication protocol between them (function calls, TCP/IP,
whatever). don't allow the engine code to include any GUI headers or
reference any GUI objects. never. under any circumstances. jMax goes
all the way, and forces the GUI to control the engine via a udp socket
from a separate process IIRC. ardour+softwerk have clean separation,
but put both the UI and engine in the same process and uses function
calls and anonymous callbacks to facilitate communication.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Nov 13 2003 - 08:22:35 EET