[...]
I got your reference from the Nigeria Exports Promotion Council (NEPC)
[...]
Okay guys, confess: who gave the mailinglist address to the NEPC?
yo!
% What's CCA?
cca. = circa
% Please don't waste your time re-implementing existing technology.
i didn't intend to just copy the programs.
i think their features are great, but the user interfaces are
big craps, so they need to be redesigned.
% Why don't you add some new
On Sat, Sep 15, 2001 at 10:06:43AM -0400, Taybin Rutkin wrote:
The format of the save file is attached. It's the savefile for the
Freeverb plugin. It uses XML. It doesn't support saving chains or
networks or lambda-calculus style plugins. I think that would be better
handled at a different
% The waveform display is the most challenging one
% I think that a widget shouldn't create peakfiles. They should be provided to it
i thought about this some days ago.
i hate peakfiles and i delete them all the time, but
in the programmer's eyeview, you just need them.
--
Racz, Mate
linux +
On Fri, 14 Sep 2001, Paul Davis wrote:
The waveform display is the most challenging one, it probably needs two
parts: A) A threaded engine that calculates the preview files and B) A
waveform renderer that could be used upon any widget.
its potentially a lot more complex than that.
i
Hi.
The title is (and hopefully remains) a joke.
On Fri, 14 Sep 2001, Paul Davis wrote:
I just want to mention one reason why I don't like using Qt myself,
not as flamebait but just to make it clear. Qt was written before the
Standard Template Library (STL) was reasonably standardized. As
On Fri, 14 Sep 2001, Phil Kerr wrote:
Hi Tommi, hi List.
This is an area I've been thinking about over the last few weeks but not
having anything to contribute yet I kept quiet. I agree with the list you
provided on what is needed.
Some other suggestions for widgets:
Piano roll / 1
I know that waveforms are difficult. That is why have not tried them at
all :-) What I had in mind is probably similar to what you described.
In more detail:
A) An object that calculates the previews in a background thread (and
serializes the requests). This thing would not have to bew very
On Mon, Sep 17, 2001 at 02:22:46PM +0300, Tommi Ilmonen wrote:
I just want to mention one reason why I don't like using Qt myself,
not as flamebait but just to make it clear. Qt was written before the
Standard Template Library (STL) was reasonably standardized. As a
result, it contains
some interesting widgets can be found in the qwt widget set from
Josef Wilgen.
Have a look at:
http://qwt.sourceforge.net/screenshots.html#screenshots
---
Werner
Hi.
On Mon, 17 Sep 2001, Jelle wrote:
However, lists are linked lists, not arrays, and thus can only forward and
backford access items, but not random access. If you want that you have to
use a vector.
for(listX::iterator i = mylist.begin(); i!=mylist.end(); i++)
mylist.erase(i)
I know.
I guess it depends on what one is used to. I have always found STL totally
painful
It really isn't. It's a bit complex at start, probably because of the
template use and the iterators. However, both of there are powerfull
things and you should understand them both anyway (not that
A quick note:
Or is the Canvas so clever that is uses genuine double buffering
(bypassing the usual socket transmission) ?
XFree86 supports the SHM extension. Ergo, when running on the same
machine as the display, there is no socket transmission of data. The
Xlib routines draw directly
STL is much easyer to handle that lowlevel arrays and such, and it can
be quite fast as well.
Sorry, IMHO STL exemplifies the phrase ``too clever by half.'' It
really needed another round of design before being released... as my
favorite example of ``things that bit me,'' if you cast a
On Mon, 17 Sep 2001, Steve Harris wrote:
On Sun, Sep 16, 2001 at 11:42:13AM -0500, Kevin Conder wrote:
My experience has been that existing XML parsers blow up when they
have to deal with large files (like a 700 page users manual). I'm worried
about what would happen if they had to
On Sun, 16 Sep 2001, STEFFL, ERIK *Internet* (SBCSI) wrote:
the same concerns are for other types of config files, and at least if you
use XML you have various standard tools that are better tested than
special purpose parser
IMHO XML parsers are no better tested than say, Apache's
If you don't believe me, mark up _War and Piece_ with XML.
Ooops, I know it's _War and Peace_...
-- kevin at kevindumpscore dot com
regarding protability:
stl is fairly new and not properly supported everywhere but it's getting
better.
erik
-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 9/17/01 8:30 AM
Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets
but stl is not 'each new library'. stl is part of c++ standard.
erik
-Original Message-
From: Tommi Ilmonen
To: [EMAIL PROTECTED]
Sent: 9/17/01 8:05 AM
Subject: Re: STL / Qt flame-war (Re: [linux-audio-dev] Audio-related widgets
with Qt ?)
I guess it depends on what one
On Mon, Sep 17, 2001 at 10:29:59AM -0500, Kevin Conder wrote:
I regularly throw around 5000-1 node ontologies (a few meg) without
any problems.
Amazing! What's your secret? Which XML parser are you using? (Is
it a context-less, non-validating, SAX-type parser? Must be.) Are
Hi all.
On Mon, 17 Sep 2001 10:35:12 +0200
Racz, Mate [EMAIL PROTECTED] wrote:
% The waveform display is the most challenging one
% I think that a widget shouldn't create peakfiles. They should be provided to it
i thought about this some days ago.
i hate peakfiles and i delete them all
Please don't add too much about this on the mailing list here, but do
consider taking a look. It's about legal changes that could be used to
stomp on Linux development in the U.S.. It'd be better for people to
know about it before it is written in stone:
OK.
Let's bring the discussion to some more objective points:
What do we want from our toolkit:
1) Ease of use to program
(there are some musicians under us, too, aren't they?)
2) Fast graphic engine
3) Maybe compatibility to other platforms (complete with
graphic engine, not only the
On Mon, 17 Sep 2001, Tommi Ilmonen wrote:
...
Can you recommend an online-version of this information? Just names of the
classes and their member functions and types in readable format. It would
be very much appreciated (since at least SGI's on-line docs are lengthy,
but difficult to
On Sun, 16 Sep 2001, Kevin Conder wrote:
What happens if the bottom of a large config file gets chopped
off? Will existing XML parsers still parse an invalid XML file? What if
someone manually edits a file and makes it invalid?
Well what happens to any parser with invalid input? Don't
On Mon, 17 Sep 2001, Paul Winkler wrote:
The wasted space of port-number is trivial, it's the redundancy that
bugs me. This is a nitpick.
I see what you mean. And I absolutely agree. How about id and value.
There. Decided.
It looks good. Paul Davis is right that we should identify the
I
Let's bring the discussion to some more objective points:
What do we want from our toolkit:
1) Ease of use to program
(there are some musicians under us, too, aren't they?)
2) Fast graphic engine
3) Maybe compatibility to other platforms (complete with
graphic engine, not only the
27 matches
Mail list logo
