Hi,
This seems like an interesting article, describeing a new kernel
service/application in 2.6.
http://www-106.ibm.com/developerworks/library/l-oprof.html?ca=dnt-441
It's called OProfiler.
OProfile can help you identify issues such as loop unrolling, poor cache
utilization, inefficient
One of my tasks as part of GMPI is to provide a draft of the requirements
doc. I turn tp you all. If you have requirements that you think should be
in GMPI - please let me know. These have to be requirements. Not
handwaving though explosions, and not wishful dreaming. Things that are
required
Well it's just requirements?
Then what about :
1) jack-transport-like and
2) LADCCA-like functionality?
the requirement resolution could sound as:
GMPI does not need such functionality,
but if it souns as GMPI _does_ need...
then it would be very welcome.
horsh
On Mon, 20 Oct, 2003 at 08:02AM -0400, Paul Davis spake thus:
I've recently been learning to use JACK, and I had a look around for
some kind of introductory article. I couldn't find one, so I wrote
the tutorial I would have wanted, as I learnt.
The tutorial is here:
On Mon, 20 Oct, 2003 at 01:19PM +0200, Mathias Lundgren spake thus:
Great, great, great! Thanks a lot! IMHO, documentation like this one is
definitely needed and something we're currently lacking. I've only skimmed
it, but I'm going to read it more thoroughly later on, since it's stuff I
1)is API monolithous or there are sub-APIs
like GMPI-audio, GMPI-seq, GMPI-control
2) Explicit versioning for API?
3) Explicit versioning for plugins?
4) uniq IDs for plugins?
who is authority?
5) format for plugin state saving:
XML? (damn its ugly!)
I vote for more YAML-like
This seems like an interesting article, describeing a new kernel
service/application in 2.6.
..
http://www-106.ibm.com/developerworks/library/l-oprof.html?ca=dnt-441
..
It's called OProfiler.
Its not new, I used it at least a year ago. It works in 2.4
http://aes.harmony-central.com/115AES/Content/Blue/PR/Bluebird.html
Tim Hockin wrote:
One of my tasks as part of GMPI is to provide a draft of the requirements
doc. I turn tp you all. If you have requirements that you think should be
in GMPI - please let me know. These have to be requirements. Not
handwaving though explosions, and not wishful dreaming. Things
Paul Davis wrote:
http://aes.harmony-central.com/115AES/Content/Blue/PR/Bluebird.html
hey paul, how about getting neumann to sell their large diaphragms
bundled with an ardour live evaluation cd ?
beat digidesign where it hurts most: in the packaging ;-
--
Progress (n.): The process through
Paul Davis wrote:
http://aes.harmony-central.com/115AES/Content/Blue/PR/Bluebird.html
hey paul, how about getting neumann to sell their large diaphragms
bundled with an ardour live evaluation cd ?
beat digidesign where it hurts most: in the packaging ;-
i said it was drivel because it is. i
On Tue, Oct 21, 2003 at 05:17:24PM +0400, horsh wrote:
1) jack-transport-like and
2) LADCCA-like functionality?
Those are not requirements, they're wishlist items. What are the
requirements?
Break it down to a set of statements that say something like GMPI must
provide... or GMPI should
On Tue, Oct 21, 2003 at 06:43:14PM +0400, horsh wrote:
1)is API monolithous or there are sub-APIs
like GMPI-audio, GMPI-seq, GMPI-control
These are requirements. It's not time to decide such things. Hopefully,
it's one main API, with as few as possible support APIs (which are required
so
On Tue, Oct 21, 2003 at 06:51:16PM +0200, Joern Nettingsmeier wrote:
* it should be elegant, or even beautiful
* it should be fun to program with
Can't exactly put that in a requirements doc, though I think it is on my
mind :)
* it *must* be easy to support in host applications
This is
On Tue, Oct 21, 2003 at 01:16:52PM -0400, Paul Davis wrote:
Paul Davis wrote:
http://aes.harmony-central.com/115AES/Content/Blue/PR/Bluebird.html
hey paul, how about getting neumann to sell their large diaphragms
bundled with an ardour live evaluation cd ?
beat digidesign where it hurts
On Tue, Oct 21, 2003 at 11:23:22 -0700, Tim Hockin wrote:
* it *must not* force any particular choice of toolkit or language upon
the implementer of either the host or the plugin
The API will be C. GUI has not been discussed much..
Except that it will be a distinct object, not
On Tue, Oct 21, 2003 at 11:20:04 -0700, Tim Hockin wrote:
2) Explicit versioning for API?
Versioning of...?
The API I expect, this is necceasry to allow multli API plugins (LADSPA
want versioned and is now).
A #define is enough.
4) uniq IDs for plugins?
who is authority?
Not
On Tue, Oct 21, 2003 at 07:50:38PM +0100, Steve Harris wrote:
We're not designing solutions, just requirements, right now. It's fine to
have a solution to a requirement, but remember that this is a bigger group.
I don't even know what YAML is. XML is a somewhat obvious answer for
Paul Davis wrote:
http://aes.harmony-central.com/115AES/Content/Blue/PR/Bluebird.html
As opposed to this (PDF link)?
http://ardour.sourceforge.net/manual.pdf
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
19 matches
Mail list logo
