ttable.14.14 1
ttable.15.15 1
ttable.16.16 1
ttable.17.17 1
ttable.18.18 1
ttable.19.19 1
ttable.20.20 1
ttable.21.21 1
ttable.22.22 1
ttable.23.23 1
}
============
================
Cheers,
Frank.
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED] /\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
audio/NAB03_CHURCH_FINAL_2.pdf
Have fun,
Frank.
--
+ --- -- - - - -
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED] /\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
-phone.
>
> Ciao
> --
> Frank Barknecht _ __footils.org__
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED] /\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
rom. I presume the Virus DSPs are running the
algoritms blockless, ie. rendering one sample and streaming it to the DACs.
This means that the delay from event reception till sound generation is
constant and virtually without jitter. When compared to the Linux sound
system this would be a luxery situ
a very lousy keyboard player, and am heading for some serious
beer now. Cheers!
>
> "Since
> > > the audio sample rate can also be used as a clock master for the alsa
> > > sequencer this would be a good option to ensure synchronisation."
>
> So
uldn't resist it.
> > Frank.
>
> Sorry, but I still claim that MIDI note pitch is equivalent to VVIDs
> when it comes to voice management. VVIDs are just more powerful. :-)
>
In MIDI all of this is typically worked around by using multiple channels
using the same sounds. I
but for some reason I get an uncomfortable
feeling seeing it; it just reminds me of over engineering and adding
unneeded complexity. I'm quite glad my MIDI devices are smart enough to do
their voice allocation....
Sorry, couldn't resist it.
Frank.
--
+ --- -- - -
number of notes:
PITCH = ((2 ^ (1/12)) ^ note)
Frank.
--
+ --- -- - - - -
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
a HDR...? These are two related,
> but slightly different problems.
not too different; only the setup times are different. I'm still glad I
don't have a analogue tape to synchronise to.
In practice, your sequences will have some bars reserved at the start of the
song in which you setup you gear.
Frank.
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
Audio Engine for use in Games or Studio. |
> | RT and off-line synth. Scripting. Sample accurate timing. |
> `---> http://olofson.net/audiality -'
>--- http://olofson.net --- http://www.reologica.se ---
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
> Obviously, you *can* use a ZLCP instead of a loop start-end pair, but
> it's a waste of memory if you have only one, non-conditional loop.
> The advantage with ZLCPs is that you can jump to them at any time for
> instant playback, and you don't *really* need that for a singl
to the POSITION change
events or discontinious position passed for the block to be processed. Fast
forwarding without SPEED hint would result in fast skipping (like seeking on
a mini disk deck); a slowdown would be euh, also result in repositioning,
but nudging a bit back every block.
Frank
--
+-
shuttle speed/direction (eg. a float; 0.0 if in pause; 1.0 if normally
running; >1.0 for fast forward; negative for reverse scrubbing etc. This
makes the plugins aware of varispeed and shuttling from the host.
just a thought.
Frank.
--
+---- --- -- - - --
| Frank van de Pol
and ease of debugging.
Frank.
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
, a setup
(I compare it to my mixing desk with some outboard processors) with varying
number of plugings for every channel would have different latency for
differenct channels.
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
rage
> synth or sampler to handle that well... It's in fact impossible to
> handle it *correctly*, unless plugins can scan back an get events
> that are before the current position, despite them being skipped.
>
> However, the real reason why you want access to absolute musical time
&
strings using the
bow.)
Though not in the scope for the instrument plugin discussion, I'd like to
see compatibility with MIDI or other real-life protocols be considered. In
the end our sequencer applications would need to transparently support both
flavours.
Frank.
--
+ --- -- -
2 at 09:15:55PM +, Bruce M Beach wrote:
>
> On Fri, 22 Nov 2002, Frank van de Pol wrote:
> > Hi Bruce,
> > the cmpci cards have the same hardware design error as the older soundblaster
> > cards (eg. SB16/AWE64). The cards lack the ability to generate interrupts.
>
&
strange tempo problem.
>
> Any thoughts or suggestions would be welcome.
>
> Bruce
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
capacitor from the power supply, hence
the exponential slope from 'spike' till drop.
Frank.
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
om for events not defined in midi spec).
>
> ...I'm not sure that is a good idea. What kind of events?
eg.
- system events like announcements of topology changes
- (N)RPNs as a 14 bit value instead of 2x 7bit
- SMF like meta data
- controls for current seque
have to
> be done
> in a driver process or a user-space sequencer application and not for every
> client
> application.
>
> I'll try to get a version of my MIDI I/O API/framework ready, but it will
> probably still
> take me some time to get f
r to compensate for the MIDI interface
> and scheduling latency so they arrive a little early instead of late
> in order to reduce jitter with MIDI messages arriving near buffer
> bounderies).
> MIDI -> audio output latency would then be slightly higher (say 2ms,
> noti
n top of a hardware device ?
>
> OSS emulation takes place in the kernel, i.e. it does not touch
> alsa-lib. therefore it only allows for direct hardware access. libaoss
> might be what you want - it redirects oss applications so that they can
> use alsa-lib functions. but it require
you're fine.
>
> --
>
> "Welcome to Muppet Labs, where the future is made - today!"
--
+ --- -- - - --
| Frank van de Pol -o)A-L-S-A
| [EMAIL PROTECTED]/\\ Sounds good!
| http://www.alsa-project.org _\_v
| Linux - Why use Windows if we have doors available?
26 matches
Mail list logo
