On Sat, Dec 14, 2002 at 02:44:48 +0100, David Olofson wrote:
Right, so dont allow plugins to talk notes... I still dont think
its necceasry, its just programmer convienvence.
It's actually more *user* convenience than programmer convenience.
Programmers that work with traditional theory
On Sat, Dec 14, 2002 at 06:48:53 +0100, David Olofson wrote:
4. There is a feature that allows plugins to tell the host
which category they would fit in. (There is some
enumeration for that somewhere.) Might be rather handy
when you have a large number of plugins installed...
This is
Hi, I've been playing a lot with bristol synth and really love it. So
much so that I've been trying to 'Jackify' it. Actually, I'm pretty
much done, but can't figure out the internal audio format. Its
interleaved floats I think, but not normalised to [-1,1]. If any of
the developers are here could
On Saturday 14 December 2002 08.18, Joshua Haberman wrote:
David Olofson [EMAIL PROTECTED] wrote:
On Thursday 12 December 2002 15.36, Steve Harris wrote:
On Thu, Dec 12, 2002 at 02:17:05PM +0100, David Olofson wrote:
(And of course, I'll make huge highres versions and icons and
stuff
On Saturday 14 December 2002 07.05, Tim Hockin wrote:
Yes - as long as the song position doesn't skip, because that
won't (*) result in tempo events. Plugins that *lock* (rather
than just sync) must also be informed of any discontinuities in
the timeline, such as skips or loops.
OK, it
On Saturday 14 December 2002 11.15, Steve Harris wrote:
On Sat, Dec 14, 2002 at 02:44:48 +0100, David Olofson wrote:
Right, so dont allow plugins to talk notes... I still dont
think its necceasry, its just programmer convienvence.
It's actually more *user* convenience than programmer
On Sat, Dec 14, 2002 at 03:35:41 +0100, David Olofson wrote:
Er, well, most people will just let the host do the wiring for
them. So it will all work fine.
...as long as they put the plugins in the right order.
Well you will almost allways use a external device - pitch converter, so
you
~
Good thinking David,
with a small set of events (tempo updates and position updates) you can
maintain a real-time view of the tempo map for all plugins. This is the same
concept as used in the ALSA sequencer API.
Since the plugins require prequeueing (because of the processing in blocks,
and
On Fri, Dec 13, 2002 at 11:33:38AM +, Steve Harris wrote:
On Fri, Dec 13, 2002 at 11:32:10 +0100, David Olofson wrote:
Very nice. Logo #2 (with the red A) gets my vote.
Hmm... Yeah, that's the first version I made. My ex GF suggested
blue, and I thought it might look more serious
On Saturday 14 December 2002 11.19, Steve Harris wrote:
On Sat, Dec 14, 2002 at 06:48:53 +0100, David Olofson wrote:
4. There is a feature that allows plugins to tell the host
which category they would fit in. (There is some
enumeration for that somewhere.) Might be rather handy
On Saturday 14 December 2002 16.13, Steve Harris wrote:
On Sat, Dec 14, 2002 at 03:35:41 +0100, David Olofson wrote:
Er, well, most people will just let the host do the wiring for
them. So it will all work fine.
...as long as they put the plugins in the right order.
Well you will
On Sat, Dec 14, 2002 at 06:04:55 +0100, David Olofson wrote:
[plugin categorisation]
This is a classic example of where external metadata is noticably
superiour.
Yeah. Especially since users may not agree with the authors' choices,
or may simply want to have plugins categorized based on
this is not meant to intimidate, rather to be a wake-up call.
it seems almost unreal (and certainly unprofessional) to me
that an instrument plugin api is being discussed here by a
bunch of people who have little to no experience in the field
of software sequencers. going into implementation
On Saturday 14 December 2002 16.20, Frank van de Pol wrote:
~
Good thinking David,
with a small set of events (tempo updates and position updates) you
can maintain a real-time view of the tempo map for all plugins.
This is the same concept as used in the ALSA sequencer API.
Since the
On Saturday 14 December 2002 18.55, Steve Harris wrote:
On Sat, Dec 14, 2002 at 06:04:55 +0100, David Olofson wrote:
[plugin categorisation]
This is a classic example of where external metadata is
noticably superiour.
Yeah. Especially since users may not agree with the authors'
* Paul Davis [EMAIL PROTECTED] [Dec 14 02 07:25]:
Hi, I've been playing a lot with bristol synth and really love it. So
much so that I've been trying to 'Jackify' it. Actually, I'm pretty
much done, but can't figure out the internal audio format. Its
interleaved floats I think, but not
What does your thingie do that sfront doesn't do?
sfront compiles SAOL / SASL text files (describing a
processing synthesis network) down to C which
compiles nicely with GCC.
SAOL is still block based AFAIK. This allows you to do some really neat
tricks with feedback, knowing that
On Saturday 14 December 2002 19.41, Tim Goetze wrote:
this is not meant to intimidate, rather to be a wake-up call.
[...many good points elided...]
Well, considering that we seem to have virtually *no* input from
people with solid experience with software sequencers or traditional
music
David Olofson wrote:
On Saturday 14 December 2002 19.41, Tim Goetze wrote:
this is not meant to intimidate, rather to be a wake-up call.
[...many good points elided...]
Well, considering that we seem to have virtually *no* input from
people with solid experience with software sequencers
A nice question to ask is 'what is time'. I suppose that there is a direct
correlation between time and sample frequency; but what to do with
non-constant sample frequency? (This is not a hypothetical situation, since
a sampled system which is synchronised to an external source, could be
facing
On Saturday 14 December 2002 23.20, David Gerard Matthews wrote:
[...]
* Is an explicitly scale related pitch control type needed?
I would argue that it's not.
Do you have experience with processing events meant for non-ET
scales? I'm looking for a definitive answer to this question, but
* Is there a good reason to make event system timestamps
relate to musical time rather than audio time?
Again, I would rather let the timestamps deal with audio time. Hosts
which work in bars/beats/frames
should be capable of doing the necessary conversion. Remember, there
http://plugin.org.uk/meterbridge/
Changes
* Greatly improved the readability of the VU meter
* Made the VU meter conform the the AES analogue equivalent levels. This
should make it more generally useful without adjustment and if you
have properly calibrated DA converters and
On Sunday 15 December 2002 00.26, Paul Davis wrote:
A nice question to ask is 'what is time'. I suppose that there is
a direct correlation between time and sample frequency; but what
to do with non-constant sample frequency? (This is not a
hypothetical situation, since a sampled system
On Sun, Dec 15, 2002 at 12:25:46 +0100, David Olofson wrote:
Well, I don't exactly know Objective C, but I've read up on the
basics, for reasons I can't remember... (Probably to see if it was
the C++ done right I was looking for. In that case, it was not,
because the contructs are *higher*
On Sunday 15 December 2002 01.10, Steve Harris wrote:
On Sun, Dec 15, 2002 at 12:25:46 +0100, David Olofson wrote:
Well, I don't exactly know Objective C, but I've read up on the
basics, for reasons I can't remember... (Probably to see if it
was the C++ done right I was looking for. In that
Steve Harris wrote:
On Sun, Dec 15, 2002 at 12:25:46 +0100, David Olofson wrote:
Well, I don't exactly know Objective C, but I've read up on the
basics, for reasons I can't remember... (Probably to see if it was
the C++ done right I was looking for. In that case, it was not,
because the
On Sun, Dec 15, 2002 at 01:19:08 +0100, David Olofson wrote:
Yes, that was my conclusion too. Its much cleaner than c++, but its
pretty slow. I'm quite supprised that Apple went for it for DSP
code.
OTOH, have you looked at how the VST host/plugin interface is
actually implemented?
On Sunday 15 December 2002 01.49, Steve Harris wrote:
On Sun, Dec 15, 2002 at 01:19:08 +0100, David Olofson wrote:
Yes, that was my conclusion too. Its much cleaner than c++, but
its pretty slow. I'm quite supprised that Apple went for it for
DSP code.
OTOH, have you looked at how
On Sunday 15 December 2002 12:59 am, David Olofson wrote:
Speaking of which, does anyone hack LADSPA plugins in C++, or other
languages?
The cmt set of LADSPA plugins is in C++.
On Sat, Dec 14, 2002 at 07:47:55 -0500, David Gerard Matthews wrote:
I'm pretty sure that Apple adopted it just to be different/moderately
incompatible. They like to trumpet
OSX's Unix kernel, and the fact that Unix apps port to OSX pretty
easily, but the coding style and
development tools
On Sun, Dec 15, 2002 at 01:59:24 +0100, David Olofson wrote:
Speaking of which, does anyone hack LADSPA plugins in C++, or other
languages?
The CMT set are all C++. That's the reason I didn't start by contributing to
it.
- Steve
On Sunday 15 December 2002 00.32, Paul Davis wrote:
* Is there a good reason to make event system timestamps
relate to musical time rather than audio time?
Again, I would rather let the timestamps deal with audio time.
Hosts which work in bars/beats/frames
should be capable of
Aaargh! Can't seem to find anything more interesting than a PDF with
a very basic overview... Is there a freely available SDK anywhere?
Would just like to say that I find some parts of that PDF a bit
scary... We're *not* talking about a lean and mean low overhead API
here, that's for sure!
13/12/02 15:46, leo zhu wrote:
Hi, guys,
I am working on a project in which I need to implement
palyback and recording on the same sound card and in
the same time.
I open the soundcard with RDWR mode and used 'select'
to wait for sound data on card and read it. After
that, I receive
On Sunday 15 December 2002 03.12, David Olofson wrote:
Aaargh! Can't seem to find anything more interesting than a PDF
with a very basic overview... Is there a freely available SDK
anywhere?
Doh! Forget about that. (Somehow, when you Google for stuff on that
kind of sites, you *always* end up
David Olofson wrote:
On Sunday 15 December 2002 00.32, Paul Davis wrote:
* Is there a good reason to make event system timestamps
relate to musical time rather than audio time?
Again, I would rather let the timestamps deal with audio time.
Hosts which work in bars/beats/frames
should be
On Sunday 15 December 2002 03.44, Tim Hockin wrote:
Aaargh! Can't seem to find anything more interesting than a PDF
with a very basic overview... Is there a freely available SDK
anywhere?
Would just like to say that I find some parts of that PDF a bit
scary... We're *not* talking about
David Olofson wrote:
Well, considering that we seem to have virtually *no* input from
people with solid experience with software sequencers or traditional
music theory based processing, I suggest we either decide to build a
prototype base on what we *know*, or put XAP on hold until we manage
David Olofson wrote:
On Sunday 15 December 2002 03.44, Tim Hockin wrote:
Aaargh! Can't seem to find anything more interesting than a PDF
with a very basic overview... Is there a freely available SDK
anywhere?
Would just like to say that I find some parts of that PDF a bit
scary... We're *not*
Well, yes, if you have more than the overview. I'm interested in time
info structs, events and that sort of stuff.
(I don't have a Mac to run that SDK self extracting binary... *heh*)
I had a mac-geek friend open it for me:
http://www.hockin.org/~thockin/CoreAudio/
Conclusion:
a. The information is there, but you have to *pull*
it from the host. Doesn't seem like you're ever
notified about tempo changes or transport events.
b. Since you're asking the host, and there are no
other arguments, there is no way that
On Sunday 15 December 2002 03.53, Tim Goetze wrote:
David Olofson wrote:
Well, considering that we seem to have virtually *no* input from
people with solid experience with software sequencers or
traditional music theory based processing, I suggest we either
decide to build a prototype base
On Sunday 15 December 2002 04.33, Tim Hockin wrote:
Well, yes, if you have more than the overview. I'm interested in
time info structs, events and that sort of stuff.
(I don't have a Mac to run that SDK self extracting binary...
*heh*)
I had a mac-geek friend open it for me:
On Sunday 15 December 2002 04.57, Tim Hockin wrote:
Conclusion:
a. The information is there, but you have to *pull*
it from the host. Doesn't seem like you're ever
notified about tempo changes or transport events.
b. Since you're asking the host, and there are no
No matter how you turn this stuff about, some things get a bit hairy.
The most important thing to keep in mind though, is that some designs
make some things virtually *impossible*.
I think this is the important point - whether the simple timestamp is
sample-time or musical time, SOME plugins
We've been talking about 'TEMPO' and 'TRANSPORT' and 'TICKS' and 'METER'
controls, which (honestly) kind of turns my stomach. This is not what
controls are meant to be doing. the answer strikes me in shadowy details:
Each host struct has a timeline member. Plugins register with the host
47 matches
Mail list logo
