Hello,
I'm from a DJ'ing background and prefer to play live and record tracks
by keeping everything as live as possible. Think of Richie Hawtin
using locked groove drum loop records and this kind of thing to make a
hybrid between DJ'ing and on-the-fly original track creation. I know
Ardour and Jack. I can create totally presequenced productions but
find that takes away my spontaneity. Are there examples out there of
these kind of set ups ? I need as many examples as possible for
encouragement if nothing else. I did start using Hydrogen to drive
external drum synths, like Yoshimi that can make drum and percussion
sounds, but the Hydrogen controls are set up for altering the included
sample sets and don't do anything to the MIDI output. I suppose I'm
trying to recreate the immediacy and spontaneity that using original
hardware 808/909/sampler set ups used to be able to create. Another
example was the immediate accessibility of Propellerhead Rebith 303.
It has a good real time 303 implementation but all the percussion was
sample based, which I want to move away from. I've found creating a
drum in Yoshimi sounds *much* richer and more dynamic than samples. So
what are you using out there ? Screen shots ?
Peace
djbarney
Hi,
In the wake of overhauling Ardour's bar-graph meters, I've taken the
time to implement corresponding needle-style meters and more.
meters.lv2 features 10 needle-style meters. Mono and stereo variants of
DIN, Nordic, EBU, BBC and VU types (which are based on jmeters by Fons
Adriaensen).
Additionally it includes a Stereo Phase Correlation Meter (needle
Display), an EBU-R128 Meter (also based on Fons' implementation) with
Histogram and History display, a Digital True-Peak Meter (4x
Oversampling, using zita-resampler), a Stereo Phase Scope (Goniometer)
and a 31 Band Spectrum-Analyzer.
Source-code, info and screenshots can be found at
https://github.com/x42/meters.lv2
They have been tested in various environments and fine-tuned to match
their corresponding real hardware type by Chris Goddard and Axel Müller.
Currently the plugins come in Gtk2 (LV2 GtkUI) and openGL (LV2
#external-ui) variants. Both versions are installed in parallel.
The main reason for this is portability and compatibility. Yet the GTK
variant UI does run in the host's GUI-thread and may slow down UI
response (in particular the goniometer). The openGL versions of the
plugins do not have this issue, but require very recent versions of
libcairo, libpixman and libpango which are thread-safe. Please see the
README included with the source.
Caveat: Note that the plugins use the LV2 idle-interface (lv2 >= 1.4.2)
The plugin-host must to be compiled with 1.4.2 or a later version of the
LV2 SDK. It also must support the http://lv2plug.in/ns/ext/resize-port/
extension. At the time of writing Ardour 3.4 and jalv.gtk from SVN >=
5129 do fulfill these criteria.
as always, any feedback is welcome.
robin
Dear fellow linux audio/multimedia enthusiasts,
It's been some time since I officially addressed the entire la* community.
This has been in great part because things just worked. Robin, who has in
great part been the mastermind behind a number of initiatives currently
being hosted on the lao server has officially stepped down a year ago (even
though I still tend to bug him way too often ;-) as the sys admin and while
we have a couple additional volunteers helping man the server, it appears
that we really need someone who will step in just like Robin did to help me
carry the burden of maintaining this huge ecosystem of sites and pages.
More so, it appears that some pages have been covered with spam/non-working
content, and given the current state of lack of adequate manpower to manage
these, my immediate response is to shut down ladspavst page which is
currently in an awful state of disrepair, filled with non-working content
and spam. The very fact it's taken me this long to spot it speaks to the
fact that I alone cannot keep up with everything that is happening on the
site. This is particularly important because if this gets any further out
of hand, the University may decide that the content hosted on these pages
goes against the very grain of what a taxpayer-run site should be hosting
and we may lose what has been so far a very generous no-limits hosting. To
put this in perspective, we've been burning steadily 1-2TB per month. For
this reason, in the interest of our great multi-site ecosystem, I will be
pulling down any sites that are not actively maintained and that also have
submitable user content (read: ability to receive unfiltered spam). If
anyone wishes to step up and maintain any of these, in order to avoid any
further mishaps like the one with ladspavst, I would like to propose that
from now on all the admins submit monthly blurbs assuring me that
everything is indeed being managed as it should be. This will certainly
help avoid situations like the one currently with ladspavst which is also
not the first time we've had problems with that site. I can and will gladly
bat for us to get us more hosting space and processing power, but this will
be heavily contingent on ensuring that our site is not hosting anything
that is potentially offensive or outright inappropriate. This does not mean
that we should not have passionate discussions on our mailing lists, but at
the same time I think one would be hard-pressed to convince anyone that
links to questionable chemical substances or worse yet inappropriate
content is something that will help us continue to enjoy this wonderful
service.
You all have been a part of this wonderful community and you all have in
many ways helped shape it into something truly amazing. Let's make sure
that we don't lose this in this process. My hope is that we will keep most
(all?) sites intact. But the reality is that we simply currently do not
have the adequate manpower to maintain all of it. More so, the server has
had its instabilities that we're trying to address and on top of that soon
we'll be forced to upgrade to a new KVM system as our University's
infrastructure transitions to its new and better iteration. This transition
will be by no means a small feat if we are to maintain an uninterrupted
service and is something that will undoubtedly require your help. If anyone
is interested and willing to assist in this process, please do not hesitate
to contact me.
Best wishes,
ico
Has anybody had a play with this? Looks, and more importantly, sounds like
it works well enough to do some useful, creative, and/or obnoxious things.
http://isse.sourceforge.net/
TAPESTREA is a similar sound editor that could do some interesting spectrum
editing. It was available from the CCRMA repository for Fedora. I enjoyed
using it but haven't been able to compile myself.
http://taps.cs.princeton.edu/
ISSE appears to be a child of TAPESTREA, with some more advanced and
smarter features but does not seem to include some of the fun, interactive
features of its parent.
If anyone knows the secret of compiling TAPESTREA for 64-bit Fedora, please
let me know.
-- Jeff
Hi.
I'd again like to invite interested users to try out rogue:
https://github.com/timowest/rogue
rogue is a multi-mode soft synth with
* 4 oscillators: VA, FM, Supersaw/square with modulation: PM, RM etc
* 2 filters: BiQuad, Moog style, SVF and Comb
* 4 envs and 4 lfos
* effects: chorus, phaser, delay, reverb
...
There are also some basic presets bundled.
Br,
Timo
Hi folks,
I know I have a lot to learn, but I'm curious about something.
Must jack or alsa be present and running for "off line" audio
processing to take place? Or are they only used for playback and
recording?
Please excuse what may, to some, come off as such basic lack of
understanding. :-)
Thanks!
Rusty
Hi folks,
Any thoughts on this error?
This began to happen just after I started playing with autotalent
ladspa plugin in nama. I don't know if the two are related.
I am using only a dual core machine so maybe I don't have enough
horsepower? The audio was studdering quite a bit when the machine was
rendering the processed audio while playing several other tracks.
Thanks!
Rusty
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I just realized that I have never properly announced midifilter.lv2,
so here it goes:
midifilter.lv2 are a collection of LV2 plugins to filter MIDI events
released in terms of the GPLv2.
The source-code can be found at
https://github.com/x42/midifilter.lv2
Thanks for JaromÃr MikeÅ¡ they are available in debian (and derived
distributions) in the 'x42-plugins' package.
Kudos to Thomas Brand who started documenting them at
http://gareus.org/oss/lv2/midifilter - much of the documentation has
meanwhile been integrated into the plugins themselves and is displayed
by LV2-hosts who support built-in doc.
So far it features 23 filters:
* Channel Filter -- discard messages per Channel
* Channel Map -- map any MIDI-channel to another MIDI-channel
* Enforce Scale -- force midi notes on given musical scale
* Eventblocker -- notch style message filter.
* Keyrange -- discard notes-on/off events outside an give range
* Keysplit -- change midi-channel number depending on note
(and optionally transpose)
* Mapscale -- flexible 12-tone map
* Chord -- harmonizer - create chords from a single note in a given
musical scale
* Delay -- delay MIDI events with optional radomization
* Dup -- unisono - duplicate MIDI events from one channel to another
* Strum -- arpeggio effect intended to simulate strumming a stringed
instrument (e.g. guitar)
* Transpose -- chromatic transpose MIDI notes
* Legato -- Hold a note until the next note arrives
* NoSensing -- strip MIDI Active-Sensing events
* NoDup -- MIDI duplicate blocker. Filter out overlapping note on/off
and duplicate messages.
* NoteToggle -- toggle notes: play a note to turn it on, play it again
to turn it off.
* nTabDelay -- repeat notes N times (incl tempo-ramps)
* Passthru -- no operation (example plugin)
* Quantize -- live midi event quantization
* Velocity Randomizer -- randomly change velocity of note-on events
* Sostenuto -- delay note-off messages, emulate a piano sostenuto pedal
* Velocity Range -- filter MIDI note events according to velocity.
* Velocity Scale -- modify note velocity by constant factor and offset
As usual, any feedback is welcome.
enjoy,
robin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJSZYEAAAoJEKCQvOAs9X8ETc0P/joBT+UiwfA/JKHiAdI+jH6W
Rj0u7Hmn3lOAuHs5Tz8BxSzd1goXRCg6PKkImrP+NTAEUUnquxtITq8mPM1mbQ8j
p1yxFJr5iThuwFz2Taa34GsbIGi9GAGKyeS7qdaRncfr1lERu1Jl5i8qrWflNccC
+xirGbPvX02uOYbajqgBDT1r4UG5CQEuapcXaBiE37CrFZWIVNsgI0RFT+I9jiUG
xWGmJL02MHOZvfJgvgiKGFVX3511xMZWm8pyPsnzN10Pwoa291D3U84PICdY/KgC
d323h2kAOi40x+731O4UBqiS6+qS0TlGrR55xlMujemMAEkBSjn6gI6GLjabMpq3
/tIZgpAYs1pzFLxCK8E+WXm+nTtJDy6RPVB0+7NMb12tgZpr8bGwEJ6fDKtJDnRY
o/9s5vAdCkkK5+o1zsD+TN7FB+anxaklcccV5P9fFADZYRwAoonLXMEhL3Y8WIo9
VQ5RccDYfc31Q4ksbqXPBs0i7A5P7cvoNbYmpvx1BrS0ueU2Nq4U/XPoW+zcvegA
f+MK35JgCk4EZMMeeFhPbhnEKcZTVCiUdz+65CRv7UsewAwkMBJMxyZmGMHF3gWp
vz6m0qT6xV8NRtzTQ6nrjZrYrBDCRrNBnfVflZy/BJ5w4Z5YaElpy6KPYnJN62at
3nELPQTMtaBgYGaOteKY
=+4IS
-----END PGP SIGNATURE-----
