On Sun, 2002-12-15 at 20:14, leo zhu wrote:
Hi, Haakmat,
I'm so glad to see your reply. But I'm still wondering
how I can implement the full duplex operation on sound
card, i.e. playback and record audio on the same card
at same time. I don't think it's a good idea that
reopen the device
On Sun, Dec 15, 2002 at 09:12:55 +0100, David Olofson wrote:
I don't get it. If you're supposed to place the scale converter
*first*, then how are you supposed to be able to apply anything
like traditional music theory, rather than pure, continous pitch
based theory? You will have to
Paul Davis wrote:
for a plugin within the system, there's no point in caring
about those that are not, except you want it to work as a
sync source. is this what you want?
just imagine two different timelines, one in 6/8, the other in 5/4,
both at different tempos. one delay plugin uses one of
Hi,
Josh Green wrote:
[..]
You may want to look into ALSA (http://www.alsa-project.org) which is
the new Linux sound architecture. Also, it would probably be good to
make sure your audio card is actually capable of full duplex and that
this feature really does work in Linux (with the
I'm so glad to see your reply. But I'm still wondering
how I can implement the full duplex operation on sound
card, i.e. playback and record audio on the same card
at same time. I don't think it's a good idea that
reopen the device when switch between reading and
writting, because I found it
You may want to look into ALSA (http://www.alsa-project.org) which is
the new Linux sound architecture. Also, it would probably be good to
make sure your audio card is actually capable of full duplex and that
this feature really does work in Linux (with the drivers you decide to
code for). I
for a plugin within the system, there's no point in caring
about those that are not, except you want it to work as a
sync source. is this what you want?
just imagine two different timelines, one in 6/8, the other in 5/4,
both at different tempos. one delay plugin uses one of them, another
uses
On Mon, Dec 16, 2002 at 01:43:03AM +0100, Tim Goetze wrote:
Standing proposal:
Host processes blocks of 'n' samples. Events are delivered with a
timestamp that says 'actuate this event at this time within this buffer'.
This is exactly what user-supplied automation is, totally randomly
On Mon, Dec 16, 2002 at 08:09:18AM -0500, Paul Davis wrote:
also, to repeat the perennial advertisement, if your application has
no reason to attach itself to a particular audio interface and might
benefit from being able to route data to/from other applications,
consider using JACK
Tempo remains in effect. Transport time is only meaningful to the
sequencer. Why should a plugin care what point in the song you are at? Why
should a plugin care if the play-pointer moves?
a tempo-sync-using plugin doesn't care about song position, true. it
only cares about tempo at a given
15/12/02 20:14, leo zhu wrote:
Hi, Haakmat,
I'm so glad to see your reply. But I'm still wondering
how I can implement the full duplex operation on sound
card, i.e. playback and record audio on the same card
at same time. I don't think it's a good idea that
reopen the device when switch
On Fri, 13 Dec 2002, David Olofson wrote:
[...valid points...]
How? It's not the host that sends these events in general; it's
other plugins. The host never touches the events in the normal
case.
Okay. I'm lost here because I don't know what a XAP app would look
like. I only know
*hehe* I offer to shut up and code unless somebody pokes me with a
sharp stick
or something and the next thing that happens is:
On Sun, Dec 15, 2002 at 07:47:07PM +, Simon Jenkins wrote:
It sounds like you'd be better off working form the Sfront SAOL code.
Well, I'm working from
David Olofson wrote:
it's much simpler. imagine the transport time rolling on
through a 'stop',
and some plugins handling things a bit
differently.
That's what I don't quite like. I'd prefer if plugins that don't care
could... well, just not care! :-)
they can, rest assured.
during
Paul Davis wrote:
how do you handle any queued events in reverse order?
by queuing them in reverse order. this is done automatically
by most plugins because they evaluate time in the current
transport direction. the transition through speed 0 requires
you to check on your queues.
tim
Sami P Perttu wrote:
Summa theologica: dump musical time, note pitch, asynchronous I/O. Use Hz
for pitch.
and never even think of using the system to actually
produce music.
tim
Paul Davis wrote:
* Host sends buffers of N samples to plugins, with a starting timestamp
* Things send timestamped events to plugins
* Timestamps are measured in whole audio samples
* Host/timeline must export/deliver:
- SAMPLE RATE (samples/sec - passed at instantiation)
- TEMPO (sec/tick -
Paul Davis wrote:
just imagine two different timelines, one in 6/8, the other in 5/4,
both at different tempos. one delay plugin uses one of them, another
uses the other. neither of these timelines are uniform across the
system, yet plugins with tempo-synced parameters need to care about
(at
Paul Davis wrote:
you absolutely need ppq for the tick system to properly map
different measures (5/4 time, 6/8 time etc) as per previous
post.
well, if ppqn is variable, then sure. but cubase and all other vst
apps have defined it to be 1, which makes it irrelevant. their pulse
or parts (there
On Monday 16 December 2002 06.12, Tim Hockin wrote:
Still, is the tempo 0, or whatever it is supposed to be at the
point where the transport is holding?
My views
Tempo remains in effect.
I agree. If you care about transport events, you can find out that
you're not moving by other means.
On Monday 16 December 2002 12.36, Steve Harris wrote:
On Sun, Dec 15, 2002 at 09:12:55 +0100, David Olofson wrote:
I don't get it. If you're supposed to place the scale
converter *first*, then how are you supposed to be able to
apply anything like traditional music theory, rather than
On Monday 16 December 2002 14.23, Frank van de Pol wrote:
[...]
I thought the assumption was to send only events scheduled for the
block te be processed. If that is the case all tempo based, musical
time references can be converted into sample relative time (eg.
sample number within the
16/12/02 16:51, Paul Davis wrote:
western music's emphasis on integral beats per bar has led to a
slipping away of a great deal of the fun and beauty to be found in
other musical traditions. i've recommended it before, and i'll do it
again now:
I find your exposition on Indian rhythms
On Monday 16 December 2002 21.21, Tim Goetze wrote:
[...]
i suggest forgetting this. VST sets it to 1 PPQN, and treats QN
as 1 beat, so the information is really quite useless. there's
no need for it given TEMPO and METER.
you absolutely need ppq for the tick system to properly map
On Monday 16 December 2002 21.50, Paul Davis wrote:
ticks are constant per quarter in a sane setup.
well, actually in ardour we discussed this at great length and
decided that giving quarter notes some kind of special status here
was a mistake. hence, ticks are constant-per-beat in its tempo
On Tue, 17 Dec 2002, Pascal Haakmat wrote:
I find your exposition on Indian rhythms fascinating and very
interesting, but I'm afraid I don't see how it relates to a discussion
about designing musical instruments.
I do not believe that the goal of instrument design should be to
accomodate
On Monday 16 December 2002 21.59, Paul Davis wrote:
[...]
so yes, ticks-per-beat is still necessary, but its a constant (1920
in ardour).
I suggest 1.0/beat for XAP. (64 bit double.)
One may claim that that's not an exact representation, but who cares,
as long as it's much more accurate than
On Monday 16 December 2002 22.30, Tim Goetze wrote:
[...]
so yes, ticks-per-beat is still necessary, but its a constant
(1920 in ardour).
there's no point in limiting this to be a fixed value.
What's wrong with 1.0? I don't see the point in introducing PPQN
here. It belongs in sequencer
David Olofson wrote:
you absolutely need ppq for the tick system to properly map
different measures (5/4 time, 6/8 time etc) as per previous
post.
I'm not sure if you absolutely need it (you *can* translate), but
indeed, it's *much* nicer when the speed of musical time depends
only on
On Monday 16 December 2002 23.08, Tim Goetze wrote:
Paul Davis wrote:
i'd be happy to hear a good example proving this wrong. but
take note that i don't accept 1/2, 1/3 and relatives as
qualifying because they can better be (and usually are)
expressed using integer numbers.
[long reasonings
David Olofson wrote:
On Monday 16 December 2002 21.59, Paul Davis wrote:
[...]
so yes, ticks-per-beat is still necessary, but its a constant (1920
in ardour).
I suggest 1.0/beat for XAP. (64 bit double.)
One may claim that that's not an exact representation, but who cares,
as long as it's
David Olofson wrote:
[tempo]
choose. quarters simply happen to work well, and there's
no need to break with convention here.
Doesn't work very well for 5/8, does it...?
it does:
5/8 = 2.5 * 1/4
thus, forcing another calculation back
from frame units is illogical.
The only relevant
On Tuesday 17 December 2002 01.50, Pascal Haakmat wrote:
16/12/02 16:51, Paul Davis wrote:
western music's emphasis on integral beats per bar has led to a
slipping away of a great deal of the fun and beauty to be found
in other musical traditions. i've recommended it before, and i'll
do
On Tuesday 17 December 2002 02.04, Taybin Rutkin wrote:
On Tue, 17 Dec 2002, Pascal Haakmat wrote:
I find your exposition on Indian rhythms fascinating and very
interesting, but I'm afraid I don't see how it relates to a
discussion about designing musical instruments.
I do not believe
David Olofson wrote:
On Monday 16 December 2002 23.08, Tim Goetze wrote:
Paul Davis wrote:
i'd be happy to hear a good example proving this wrong. but
take note that i don't accept 1/2, 1/3 and relatives as
qualifying because they can better be (and usually are)
expressed using integer
On Tuesday 17 December 2002 02.33, Tim Goetze wrote:
[...]
Anyone here ever used non-integer # of beats/bar, and/or weird
note lengths?
non-integer is not proven to be needed i think. if you say you
need 9.5 beats per measure, simple make that 19 half beats. it
is a lot simpler to implement
16/12/02 20:04, Taybin Rutkin wrote:
On Tue, 17 Dec 2002, Pascal Haakmat wrote:
accomodate every possible musical expression under the sun. A musical
instrument is always part of a culture and a history and this defines
its use.
But in this case, they're designing a system for
On Tuesday 17 December 2002 02.41, Tim Goetze wrote:
David Olofson wrote:
On Monday 16 December 2002 21.59, Paul Davis wrote:
[...]
so yes, ticks-per-beat is still necessary, but its a constant
(1920 in ardour).
I suggest 1.0/beat for XAP. (64 bit double.)
One may claim that that's
about arithmetic: float operations, as you know, introduce
round-off error. integers can be used in accumulators with
much less inconvenience.
sorry, its just wrong.
prove it.
sorry, when i said this, i meant something more like:
sorry, its just not right to force integral values.
in
On Tuesday 17 December 2002 02.47, Tim Goetze wrote:
David Olofson wrote:
[tempo]
choose. quarters simply happen to work well, and there's
no need to break with convention here.
Doesn't work very well for 5/8, does it...?
it does:
5/8 = 2.5 * 1/4
That's what I mean; that doesn't
David Olofson wrote:
On Monday 16 December 2002 23.08, Tim Goetze wrote:
Paul Davis wrote:
i'd be happy to hear a good example proving this wrong. but
take note that i don't accept 1/2, 1/3 and relatives as
qualifying because they can better be (and usually are)
expressed using integer
On Tuesday 17 December 2002 03.11, Tim Goetze wrote:
David Olofson wrote:
On Monday 16 December 2002 23.08, Tim Goetze wrote:
Paul Davis wrote:
i'd be happy to hear a good example proving this wrong. but
take note that i don't accept 1/2, 1/3 and relatives as
qualifying because they can
David Olofson wrote:
On Monday 16 December 2002 21.59, Paul Davis wrote:
[...]
so yes, ticks-per-beat is still necessary, but its a constant (1920
in ardour).
I suggest 1.0/beat for XAP. (64 bit double.)
this is awful. 1 tick per beat provides lousy resolution. when
something happens 1/3rd of
On Tuesday 17 December 2002 03.19, Pascal Haakmat wrote:
16/12/02 20:04, Taybin Rutkin wrote:
On Tue, 17 Dec 2002, Pascal Haakmat wrote:
accomodate every possible musical expression under the sun. A
musical instrument is always part of a culture and a history
and this defines its use.
for no special reason and with the intent of public delight,
here's an excerpt from The Raga Guide, published by Nimbus
Records in association with the Rotterdam Conservatory of Music,
by Joep Bor, Suvarnalata Rao, Wim van der Meer and Jane Harvey,
musicians on the CD set are: Hariprasad
David Olofson wrote:
the good thing about 1920 is it is divisible by both 3 and 4;
this lets both triplets and even sub-beats evaluate to integer
ticks.
...which get rounded to the nearest integer audio sample frame
anyway, as far as events are concerned.
but in any sane system built to be
On Tuesday 17 December 2002 03.23, Paul Davis wrote:
about arithmetic: float operations, as you know, introduce
round-off error. integers can be used in accumulators with
much less inconvenience.
sorry, its just wrong.
prove it.
sorry, when i said this, i meant something more like:
On Tuesday 17 December 2002 03.40, Paul Davis wrote:
[...]
i've heard l.shankar, the phenomenal player of a double-necked
electric violin (he's not bad on the traditional instrument as
well) count indian talas in 3.5 beats and 9.5 beats. he counts:
1--2--3-1--2--3-1--2--3-1 ...
and
David Olofson wrote:
1) it is simply not the way counting time as a musician works.
if your measure said 3.5 / 2, you'd count 7 quarters.
In that case yes - but with longer bars, I'd try to find a reference
in between my notes. Let's take Paul's nice example. To play the 9
1/2 part, I'd
Pascal Haakmat wrote:
16/12/02 16:51, Paul Davis wrote:
western music's emphasis on integral beats per bar has led to a
slipping away of a great deal of the fun and beauty to be found in
other musical traditions. i've recommended it before, and i'll do it
again now:
I find your exposition
Sorry, forgot to add:
Pascal Haakmat wrote:
Modern technology (and software in particular) allows us to design
incredibly flexible instruments without needing to commit to any
particular musical tradition at all. That doesn't mean that doing so
is also always a good idea.
I know what you're
David Olofson wrote:
actually and mathematically proving this unfortunately is
beyond me, you have to try it yourself.
Well, why don't we ask someone who actually plays this kind of music
seriously? I can only tell you how *I* count when dealing with
complex rhythms - and I don't do it
Tim Goetze wrote:
[33] Over eighty-five percent of the ragas on the CDs have been
performed in tintal.
tim
Way off-topic: I wonder if that's due to western influence, since the 16
beats of
tintal somewhat resemble the 4-bar 4/4 phrase of western music.
However, tintal
can also be
53 matches
Mail list logo
