This might be interesting to some of you:
The newly granted patent US6625629 "System and method for signal processing
using an improved convolution technique" owned by Microsoft, covers
partitioned convolution. The patent was filed in May 2000, and granted in
September 2003.
This is in most claims the same convolution algorithm previously patented by
Lake Technology with priority date back in July 7 1992, US5502747. And that
is in most claims the same algorithm as invented and published by Soo and
Pang and others prior to 1992, which is the same algorithm used in my
software BruteFIR.
Isn't the patent system wonderful? The requirements "new" and "non-obvious"
were in practice scrapped a long time ago...
Anyway, Microsoft does as far as I know not have the tradition to harass free
software developers as Lake has, so I don't think the fact that another one
owns the partitioned convolution algorithm will cause any more trouble.
It would be interesting to know what Lake thinks about this. If Microsoft has
patented it, they probably use it, and then Lake might want them to pay
royalty, or else....
/Anders Torger
hi all,
a new, completely redone version of my valve-inspired preamp plugin is
up. improvements over the predecessor include:
* smoother distortion; clipping kicks in veeery gently
* a better 'gain' knob model and balance between input and output
loudness
* initial hi-pass filtering now part of the unit
* gentle mid-range frequency boost
* closer matching of the original circuit's harmonic distortion
characteristics
* 4x oversampling at 44-48 kHz sample rates
more info and the plugin sources at http://quitte.de/dsp/preamp.html
enjoy,
tim
From here:
http://www.native-instruments.com/index.php?fsfeatures_us
"In TRAKTOR FS the Final Scratch System has a high-performance DJ
software that has been specifically optimized for the needs of Final
Scratch users.
System Requirements:
*Runs on standard PCs, operating on Linux OS (all necessary software
included)"
from here:
http://jane.no-ip.com/traktor-debian.html
"This is work in progress but posted for people who wish to get Native
Instruments / Standon Magnetics Final Scratch version of Traktor to work
on their own linux distribution rather than the stripped installation
that they provide on the CD. Please note this may not work for you at
all - and I've tried to be as direct as I can with the documentation -
It's assumed that you've played in a shell before, and have some
familiarity with linux.. "
I'm not a FS user but from reading the page it seems that they are using
Wine to run it under
linux from a self bootable CD.
Anyone got more infos about this ?
(I'd interested if Wine is performant enough etc ....)
from here:
http://djzorro.mynet.it/
"Dear Visitor,
these "patches" (try to) add (a sort of) networking ability to a
GNU/Linux distribution made by Nativ
e Instruments as a OS for their Traktor Final Scratch software. "
For curiousity I downloaded one of the ZIP files.
It unzips to a .tuc and .tup file.
The tup file is a tar.bz2 file so just rename and untar it.
For example in the boot dir you see two kernels:
2.4.22pre1-ni 2.4.22pre1-z
Are these standard kernels, did they use patches or did they write their
own ?
(where are the sources ? are they objeing the GPL license ?)
Comments ?
Benno
http://www.linuxsampler.org
Thanks to the great reverse engineering work of Paul Kellett and Ruben van
Royen I created this library. libgig is a C++ cross-platform loader library
for Gigasampler files.
The library consists of three parts:
- RIFF classes for parsing arbitrary RIFF files
- DLS classes which use the RIFF classes to parse and provide access to DLS
level 1 and 2 files
- gig classes which are based on the DLS classes and provide the necessary
extensions for the Gigasampler file format
So you can also use the library for loading DLS files or RIFF files in
general, but the main focus is the Giga format, which you might get from the
name of this lib ;)
You can get the sources coming with tools / demo apps, API documentation, UML
diagram and a short kick start docu at:
http://stud.fh-heilbronn.de/~cschoene/projects/libgig/
I claim that this library provides all articulation data the Gig format
contains. If you think I might miss some, let me know!
The library should be compilable on all platforms. Nevertheless I don't own a
non Intel system, so I can't test it; maybe it needs some minor adjustments
but I took care about endian and word size correctness when I wrote the lib,
so I'm quite confident it will work! Let me if you tried it on a non Intel
system!
Best regards
Christian Schoenebeck
Hi,
I regularly read the german "Keyboards" magazine and in some
occasions they tested some Windows softsynths/HDR apps and measured
voicecount/number of parallel instances of plugins.
They usually talk about "3 msec latency" case but in one occasion
I've seen they talked about "1.5msec latency" too.
I could be wrong but I assume they are misinterpreting "fragment
latency" and total latency, fooling users into believing that the
latency numbers they gave refered to the total latency.
My question is: since the Hammerfall cards always use two fragments,
are the buffer size (latency) figures shown in the diagram below:
http://www.rme-audio.de/images/hdsp/mf_set.gif
refered to the whole buffer or to a single fragment.
for example take the 1.5msec (64 samples) case.
Does that mean 64 samples in total (32samples/fragment = 0.75msec per
fragment) or 64 samples per fragment (1.5msec per fragment thus a total
3msec).
I'm sure Paul D. and other Hammerfall experts will be able to enlighten me.
Sorry for the question but I just wanted to be sure that it's not the
case where per-fragment latencies as sold as total latencies since lower
latency numbers are always cool :-)
cheers,
Benno
http://www.linuxsampler.org
Hi,
i was thinking about latencies of softsynths and how cubase vst handles
this when playing back recorded midi tracks as opposed to playing the
softsynth directly. I'm talking about the vst-softsynths here. not the
ones that get controlled via usual midi ports.
It seems that during playback of a prerecorded midi track cubase vst
knows the latency of the softsynth and and arranges for that so that the
softsynth is really tight [no offset to other recorded audio material].
This is, of course, only possible because the midi signal if routed
vst-internally is handled different than midi that gets sent out.
I suppose that todays available audio/midi-sequencer support midi in a
form that it is synchronized to the latency of the audio signal that is
sent out. So, if the audio signal takes 2*128/44100s [2 buffers a 128
frames] to reach the ear of the user, then the prerecorded midi signal
is delayed this exact amount of time, because midi signals is supposed
to be of zero latency. And for external hardware synthesizers this is
pretty much true. This way prerecorded audio and midi tracks are nicly
synchronised during playback.
Now, for the case of a sofstsynth this scenario doesn't fit, because the
synth is not zero latency. This means that a "tight" midi track is
audible with the softsynths output latency.
Now, Jack is really an audio server but it could also be used to
communicate the latency of the softsynth to the Audio/Midi Sequencer. I
know there's calls to get the output latency of physical output ports.
But it would be nice to have calls to ask for the physical output
latency of clients [this value can be different for different clients -
maybe with different output devices].
This way, the audio/midi-sequencer could ask jack for a list of clients
and offer this choice to the user who then can select which midi tracks
correspond to which softsynth. The Sequencer could then send the midi
events a tad bit earlier [the output latency of the softsynth].
What do you think? I have no insight into the implementation details of
jack, so i don't know how possible this scenario is and if it fits with
design decisions.
Regards
Florian Schmidt
Cheesetracker is a portable Impulse Tracker clone. It supports all the main
Impulse Tracker and FastTracker/SoundTracker features, plus many more.
It is licensed under the GNU Public License. It runs under
Linux/BSDs, MacOSX(QT/Mac or Qt/X11), or Win32(Cygwin).
It can be obtained at http://cheesetronic.sf.net
For those unfamiliar with trackers, this is basically an
all-in-one sequencer/sampler/sample editor/mixer/fx processor bundle,
wich provides fast and flexible means for professional grade
music composing.
Including in the release are tutorials and documentation.
Volunteers to help to better documment it would
be highly appreciated.
The ChangeLog for this release follows:
v0.9.0
------
-Removed sample mode (Scream Tracker 3 mode) as It's obsolete and not needed
for backwards compatibility.
-Instruments are now layered and can perform up to 4 simultaneous voices with
individual parameters each.
-Added an effect buffers system. Instruments are now routed to custom buffers
(each with individual effect chains), which can also re-route to other
buffers. This allows to create very complex effect routes for realtime
processing.
-Effect buffers are "process on demand", which means they are smart enough to
notice when they are doing nothing, thus disabling themselves.
-Added a few internal effects: Amplifier, Clipping/Distortion, Recursive Delay
Line, Stereo Enhancer, Chorus and Reverb.
-Added a LADSPA effect source plugin. LADSPA plugins can be added to the
chains.
-Created new file formats that save all the new features: .CT (CheeseTracker
Module) .CI (Cheesetracker Instrument) and .CS (CheeseTracker Sample)
-Added preview to the sample file selection box, just hilite a file and use
your keyboard to play notes (/ and * work in there too).
-Readded JACK Driver (Kasper Souren)
-Added RTAUDIO driver, allows for porting to Win32/ASIO and OSX/CoreAudio
-Fixed some big endian compatibility issues. CheeseTracker should work fine
again on big endian machines.
-MacOSX port and build system/build fixes courtesy of Benjamin Reed
-Fixed tons and tons of bugs.
AND NOW PLEASE READ: How fast CheeseTracker reaches version 1.0 depends on
YOU. The focus of this version is STABILITY. Because of this, I need to
receive as many bug reports as I can, both program and build system. If you
find a bug, I'd be enormously grateful if you submit it. Even if it is an
obvious bug to you, chances that other people will find and report the same
bug are much smaller than what you may think. If you dont report a bug that
annoys you, the chances of it reappearing in the next version will allways be
higher.
Planned for 1.0.0:
-=-=-=-=-=-=-=-=-
-Rock Solid stability
-WAV exporting
-A hopefully working Windows port. This depends mainly on the Qt-Win32
project. If you are a good Windows programmer and would like to see
CheeseTracker working in there sooner, please give those guys a hand!
Enjoy!!
Juan Linietsky
On Monday 27 October 2003 15:08, Benno Senoner wrote:
>Assume I press C2 with velocity 50 pedal up, the C2-pedalup (associated
>to velocity 50) sample sounds.
>Now I press the sustain pedal and press C2 with velocity 100.
>What should the sampler do ? Quickly fade out the C2-pedalup
>(velocity-50) note and trigger the
>C2-pedaldown (velocity 100) note ?
>And of course when you release the pedal all sustained notes will get a
>note-off.
I am a piano player.
I would expect the C2 note to be replaced with the next attack on that note.
If the pedal is pressed, the damper stays up, so the next attack will be the
hammer hitting the strings, and the sounding note is not faded out before.
So I think you should fade out the previous note after or on the attack of the
next one. Maybe even a lot later. There is an adding resonance effect if you
keep hitting the same note with the pedal down, but that is probably the
sympathetic vibrations from the other strings.
If the pedal is not pressed the damper returns to the string as the key is
released to play the next attack. You will get a note off message then
anyway.
Note that releasing the pedal should only send note-off to those notes that
are sounding, but whose key is not pressed. If you have keys pressed down,
the dampers will be up, regardless of the position of the sustain-pedal. So
these should continue. I have no idea if digital piano's actually do this
correctly, but it is the way a accoustic piano works.
Gerard
electronic & acoustic musics-- http://www.xs4all.nl/~gml
Hi all,
There's now a mailing list specifically for LADCCA discussion,
ladcca-devel. You can subscribe from here:
http://mail.nongnu.org/mailman/listinfo/ladcca-devel
Bob
--
Bob Ham <rah(a)bash.sh>
"At some point, keystroke recorders got installed on several machines at
Valve. Our speculation is that these were done via a buffer overflow in
Outlook's preview pane." -- Gabe Newell on the Half-Life 2 source leak