http://www.notam02.no/arkiv/src/
Mammut will FFT your sound in one single gigantic analysis (no windows).
These spectral data, where the development in time is incorporated in
mysterious ways, may then be transformed by different algorithms prior to
resynthesis. An interesting aspect of Mammut is its completely
non-intuitive sound transformation approach.
This is very minor update. If you already have mammut, theres probably not
much point in upgrading. The "big" change in this release is the first
entry in the changelog. I must also warn that mammut can be a bit hard
to compile up, now that pygtk1 has been replaced with pygtk2 in all
recent distributions I know about.
0.16 -> 0.17
-Initialize sound at startup, so that mammut appears in jack patch bays.
-Removed the included sndlib binary.
-Added a point in the INSTALL file about how to configure mammut to
find the pygtk1 files.
-Added a note in the INSTALL file about that sndlib for some reason
does not work with delta cards when using the alsa driver. The oss
driver (under alsa emulation), and the jack driver works just fine.
--
iain duncan wrote:
>>I think that 'groove quantise' does have quite a specific meaning :
>>> To take the timing from one midi part, and apply it to another.
>>> So, you get the midi timing from a real drummer grooving away and
>>apply
>>> it to your beat. Then it pulls your beats to the nearest beat in the
>>> groove, rather than to the normal 16th or whatever.
>
>
>That was one sequencer's implementation of the term, but certainly not >a
>universally accepted strict definition.
I guess so. It's only Cubase that calls it that. Emagic logic, Fruity
Loops, Pro Tools, Groove Slicer, Cakewalk Sonar and Digital Performer
all call using the timing from one part on another a 'groove template',
which is much clearer.
If the 'groove' was pulling the notes towards a dotted or triplet feel,
I'd call it 'shuffle' or 'swing' to differentiate it.
'groove quantise' should perhaps be used when a sequencer or drum
machine is applying a groove more complex than a simple triplet feel,
but not using a template based on another recording.
>Iain
HI all,
There was a discussion on the LAU list about jamin using FFT
based filtering. I I missed much of the discussion but that
particular point just jumped out at me.
Has anyone thought of trying linear phase FIR filters instead of
FFT methods? Any filter that can be specified in the frequency
domain can be implemented in the time domain and vice-versa.
Often (but not always), the time domain version is significantly
cheaper in CPU cycles.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Neither noise nor information is predictable."
-- Ray Kurzweil
Hi all,
Does anyone know of a page somewhere that explains just what (on a
developer level) MIDI "groove" is? I want to implement it in a
sequencer, but all I can find is user documentation pages with useless
information.
Is it as simple as each note having a time offset (ie snare is early .5
ms, hi-hate late 1ms, etc.) or something more?
Thanks..
-DR-
Hi!
I want to programme my mic and my speakers on my FC2 box. I am running
KDE. Is there a library which I should look at or is the ALSA API the way
to go?
Thanks,
Catalin
--
<<<< ================================== >>>>
<< We are what we repeatedly do. >>
<< Excellence, therefore, is not an act >>
<< but a habit. >>
<<<< ================================== >>>>
Dave Robillard wrote:
>Hi all,
>
>Does anyone know of a page somewhere that explains just what (on a
>developer level) MIDI "groove" is? I want to implement it in a
>sequencer, but all I can find is user documentation pages with useless
>information.
>
>Is it as simple as each note having a time offset (ie snare is early .5
>ms, hi-hate late 1ms, etc.) or something more?
>
>Thanks..
I think that 'groove quantise' does have quite a specific meaning :
To take the timing from one midi part, and apply it to another.
So, you get the midi timing from a real drummer grooving away and apply
it to your beat. Then it pulls your beats to the nearest beat in the
groove, rather than to the normal 16th or whatever.
I seem to remember having some floppys of grooves back in the atari days
and doing this with midi shaker patterns and the like, but it's been a
long time....
Hans Fugal:
>
> ALSA. If you want to tie yourself to KDE and endless misery, try artsd,
> but I warned you.
>
Hmmm, I think the alsa api is a bit huge/complicated. I would never
reccomend doing alsa directly, and I think it was a very bad advice
actually. Check out portaudio, sndlib or jack instead, which provides
easier interface to the soundcard than alsa, and works on top of alsa (and
others).
--
Hello,
I trying my first steps with Supercollider. Build and install
went without any probles, and I learned just enough elisp to
get scel running in emacs.
Now the problem seems to be that sclang and scsynth do not
talk to each other. How is the sclang -> scsynth UDP link
configured ? There is no option in sclang to set the port
number it sends to so probably this is fixed. OTOH, scsynth
requires a port number for the -u option, but what should
this be ?
TIA,
--
Fons
The second stable release (0.9.0) of JAMin - the JACK Audio Mastering
interface is now available for download.
JAMin is a GPL-licensed, realtime mastering processor designed to
bring out the detail in recorded music and provide a final layer of
polish. Every effort has been made to ensure a clean, distortion-free
signal path. All processing elements use linear-phase filtering to
eliminate phase distortion.
JAMin runs on Linux using the JACK Audio Connection Kit, a low-latency
audio server. JACK connects multiple applications to a single sound
device, and also share audio among themselves. We rely on other JACK
applications (like ardour, ecasound, or rezound) for playback and
recording.
Homepage
http://jamin.sourceforge.net/
Download
http://prdownloads.sourceforge.net/jamin/jamin-0.9.0.tar.gz?download
New dependencies (since jamin-0.8.0)
swh-plugins >= 0.4.6 <http://www.plugin.org.uk>
liblo >= 0.5 <http://plugin.org.uk/liblo>
(optional, for OSC scene change control)
All other dependencies remain unchanged, the README file has a
complete list.
Usage instructions
http://jamin.sourceforge.net/Using_JAMin.html
Changes since jamin-0.8.0
* Limiter improvements:
-- uses new fast lookahead limiter (LADSPA:1913) from the
swh-plugins >= 0.4.6. The old limiter had some undesirable
sonic artifacts.
-- changed order of final gain and limiter stages.
* OSC control for scene changes:
-- accepts "osc.udp://localhost:4444/jamin/scene" messages
-- new `jamin-scene' command sends them
-- new jamin-cont plugin (LADSPA:1912) sends scene change
messages to the JAMin process via OSC.
(This plugin works with ardour, ecamegapedal and
applyplugin, but segfaults in jack-rack when removed.)
* Increase number of scenes from 6 to 20
* GUI improvements
-- extensive context-sensitive help
-- color editor for highlights and text
-- options pulldown menu for spectrum, crossfade, and EQ
* Better bypass control
-- specific bypass controls for EQ and limiter
-- separate Active/Solo/Bypass for each crossover band
* Global state settings saved in XML file.
* Expanded Russian translation
* Many bug fixes.
--
joq
http://sourceforge.net/projects/liblo/
Theres a mailing list, liblo-devel.
For those who dont know, liblo is a GPL'd implementation of the OSC
protocol, which is a Remote Procedure Call language, designed for audio
software.
http://www.cnmat.berkeley.edu/OpenSoundControl/
I feel that liblo is now mature enough to stand on its own, so I'm moved
it to sourceforge. I welcome help and advice from anyone who feels like
giving it, though I do want to stop the API getting too sprawly.
The current state is that I've just added UNIX domain and TCP transport
support, but they are a bit rough around the edges.
The current contents of the TODO list are:
* Bundle support [needs NTP, argh]
* Add source address to received messages
* More/better regression tests
* More/better example code
* Normalise URI handling [needs discussion]
* GTK/Qt/etc. tie code [maybe belongs in another library]
* OSC pattern matching [still not sure about this one]
* Rendevous/OpenWhatever (eg. howl) service discovery [low priority]
* Add a JACK transport layer [maybe, low priority]
* Make TCP work to spec (currently the TCP server only reads the 1st packet
from every conneciton) [low priority]
Cheers,
Steve
