David's advice is right on.
> why not use audio rate control ports? Or some sort of hybrid, allowing
> you to
> switch as needed - but that quickly becomes a complexity explosion...
I use a hybrid where ports are audio-rate AND each port has two states:
'streaming' or 'static'. So if you don't want audio-rate modulation, you
pass a buffer of identical values and set the port state 'static' (not
changing).
The advantage is: 'Dumb' plugins need no special-case code, just write them
as though the port was always audio-rate, one single simple code-base.
'Smart' plugins can query the port state and switch to more efficient code
when the port is 'static', e.g. read only the first sample, treat it like a
block-accurate parameter (i.e. Far more efficient).
Best Regards,
Jeff
Hi,
I spent a few hours here and there to work on jass. Thus I give you
release 0.9 which is fairly feature complete. But it might still have a
gazillion of bugs. So please test, before I go 1.0..
http://shirkhan.dyndns.org/~tapas/Jass-0.9.tar.bz2
Jass - A Jack Simple Sampler
Qt4-, libsamplerate-, libsndfile-, jack_midi-, jack_session-,
ladish-L1-enabled sampler..
Changes (AFAICT):
* graphical editors for most parameters (those can be resized to suite
your needs)
* waveform display to set sample start/end, loop start/end
* keyboard widget to set note, min note and max note
* a retarded dial_widget that is barely usable :D
* global voice allocation (you can set the global polyphony per setup in
the xml file
* ADSR envelope that actually works
* show/hide some parameter sections
Screenshot (showing all parameter editors):
http://i.imgur.com/Ssc4F.png
Regards,
Flo
Hey everyone, especially those who have been helping me with me
architecture questions. I'm wondering whether some of you would be
interested in helping in a simple advisory/editorial capacity if I were to
try to write up a wiki or e-book of some kind on real time audio
architecture. It seems to me like there is a lot of knowledge here on it,
and not very many (if any) good starting points for such things. I've found
decent references on the dsp side of audio coding, but not seen anything on
'how to put together a real time audio app from a-z' kind of thing. I find
writing docs helps me clarify things in my head, I'd be interested in doing
some writing if I know that people who know what they are doing would be
interested in advising and correcting. I figured if I put it online it
might be a good source of publicity for your work and we could link back to
projects ( ardour, etc, )
It would take a while of course, but might also help people new to these
lists and give us all some thing to point at and say: there's a good write
up on that here ->
thoughts?
iain
Guitarix release guitarix2-0.20.0
After much code shuffling, refactoring and testing we are happy to
release "whizzing abacus" guitarix2-0.20.0. Thanks to all testers and
special thanks to rosea grammostola for his patience.
Guitarix is a tube amplifier simulation for jack, with effect modules
and an additional stereo effect chain.
Please refer to our project page for more information:
http://guitarix.sourceforge.net/
new features and bugfixes in short:
* important bugfix: convolver (cabinet, presence) in 0.19.0 only
worked when samplerate was 48000Hz
* avoid connect already connected ports
* always save state on exit (in earlier versions state was not saved
when presets where selected)
* separation of engine and UI
if you always wanted to use Guitarix headless or embedded, now
there's a chance :-)
* now its possible to set the reference pitch of the tuner
* remember currently selected preset in guitarix state file
* display selected preset / factory preset in window title and patch
info window
* updated factory settings from funkmuscle
* reworked guitarix operation under a jack session manager
* error popup window in addition to existing logging facility
* command line option to set instance name (determines jack client
names and state file to use)
* some more work to support localization
* upgraded to zita-convolver version 3
* other smaller changes and clean-ups
download site:
http://sourceforge.net/projects/guitarix/
please report bugs and suggestions in our forum:
http://sourceforge.net/apps/phpbb/guitarix/
here you can find a couple of examples produced by guitarix users:
http://sourceforge.net/apps/phpbb/guitarix/viewtopic.php?f=11&t=83
have fun
_________________________________________________________________________
For extra Impulse Responses, guitarix uses the zita-convolver library,
and, for resampling we use zita-resampler, both written by Fons
Adriaensen.
http://kokkinizita.linuxaudio.org/linuxaudio/index.html
We use the marvellous faust compiler to build the amp and effects and
will say thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://q-lang.sourceforge.net/examples.html#Faust
: Yann Orlary
http://faust.grame.fr/
________________________________________________________________________
guitarix development team
Further to the conversation about Python to C++ ( with many helpful
responses, thanks everyone! ).
For my particular case, no drop outs is critical, and I really really want
to be able to run multiple UIs on lots of cheap machines talking to the
same engine over something (osc I expect). So I'm ok with the fact that
user input and requests for user interface updates may lag, as the queue is
likely to be really busy sometimes. I'm imagining:
Engine thread, which owns all the data actually getting played ( sequences,
wave tables, mixer/synth/effect controls, the works )
- gets called once per sample by audio subsystem ( rtaudio at the moment )
- does it's audio processing, sends out audio
- loop by Magical Mystery Number 1:
- get message off input queue describing change to a data point (
sequence or sample data )
- updates data point
- loop by mystery number 2:
- get message off 2nd UI queue requesting the state of a data point
- sends back a message with that data to the requester
done
GUI thread
- keeps it's own copy of whatever data is pertinent to that particular gui
at that point
- sends a bunch of requests if user changes the view
- sends messages data change requests according to user actions
Here's my question, how do I determine the magical mystery numbers? I need
to make sure engine callback is always done in time, no matter how many
messages are in the queue, which could be very high if someone is dropping
in a sample of audio. By making the data point messages very simple, I hope
that I'll have a pretty good idea of how long one takes to process. It's
just a lock-get-write to simple data structure. But how much audio
processing has happened before that point will be variable. Anyone have
suggestions on that? Is the system clock accurate enough to check the time
and see how much a sample period is left and make some safe calculation
with headroom left over there? It is totally ok for the queue and the
inputs to lag if the audio number crunching goes through a spike.
suggestions most welcome. (including 'that design sucks and here's why')
thanks
iain
Figured this might be of some interest to someone around here - and either
way, it's all done on Linux, and it will be released on Linux. ;-)
(Original announcement post at the end!)
-------------------------------------------------------------------------
The whole game engine will probably go Free/Open Source eventually; older
versions of parts of it already are. The synth engine will be JACKified and
open sourced as soon as I get around to it! Going to support JACK in the game
as well, as I use it on my devsystem all the time anyway.
No idea if anyone will ever understand or care for this strange beast of a
sound engine, but anyway... :-D For your amusement, here's the "lead synth"
used for the theme and some other melodic features in the song:
CuteSaw(P V=1)
{
!P0 sp, +P sp, w saw, p P, a 0, !er .05, !vib 0, !tvib .01
.rt wg (V + a - .001) {
sp (vib * 6 + rand .01)
12 { -sp vib, +p (P - p * .8), +a (V - a * er), d 5 }
12 { +sp vib, +p (P - p * .8), +a (V - a * er), d 5 }
+vib (tvib - vib * .1)
}
a 0, d 5
1(NV) {
V NV
if NV {
vib .005, tvib .005, er .05, wake rt
} else {
tvib .02, er .02
}
}
2(NP) { P (P0 + NP), p P }
}
Yeah, I was in a neurotically minimalistic kind of mood when I designed that
language... But, it Works For Me(TM)! Less typing ==> quicker editing. ;-)
(The original version of ChipSound, with a more assembly-like scripting
language, was less than 2000 lines of C code. It's slightly below 4500 lines
now, compiler included.)
When playing a note, a voice with its own VM is started, and set to run this
script. The VM runs in unison with the voice, alternating between audio
processing and code execution. Thus, timing is sub-sample accurate, allowing
the implementation of hardsync, granular synthesis and the like without
specific engine support.
Timing commands can deal in milliseconds or musical ticks, making it easy to
implement rhythm effects, or even writing the music in the same language, as
I've done here.
Voices (microthreads) are arranged in a tree structure, where each voice can
spawn any number of sub-voices it needs. Messages can be sent to these voices
(broadcast or single voice), allowing full real time control.
Oscillators currently available are wavetable (mipmapping, Hermite
interpolating, arbitrary waveform length sampleplayers) and "SID style" S&H
noise. It's possible to use arbitrary sampled sounds and waveforms, but so far
I've only been using the pre-defined sine, triangle, saw and square waveforms,
and the noise generator.
-------------------------------------------------------------------------
Kobo II: Another song WIP
-------------------------
"Yesterday, I started playing around with a basic
drum loop made from sound effects from the game.
The usual text editor + ChipSound exercise, using
only basic waveforms. I sort of got caught in the
groove, and came up with this: [...]"
Full story:
http://olofsonarcade.com/2011/11/06/kobo-ii-another-song-wip/
Direct download:
http://www.olofson.net/music/K2Epilogue.mp3
--
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://consulting.olofson.nethttp://olofsonarcade.com |
'---------------------------------------------------------------------'
Paul Davis:
> On Wed, Nov 2, 2011 at 12:23 AM, Iain Duncan <iainduncanlists(a)gmail.com>
> wrote:
>> Hi, I'm working on an a project that I intend to do using the STK in a
>> callback style, but am hoping I can prototype the architecture in python
>> until I've figured out the various components and their responsibilities
>> and
>> dependencies. Does anyone know of any kind of python library ( or
>> method? )
>> that would let me simulate the way callback based STK apps using RTAudio
>> work? IE I want to have a python master callable that gets called once
>> per
>> audio sample and has a way of sending out it's results to the audio
>> subsystem.
>>
>> I've found a bunch of python audio libs but it doesn't seem like they
>> work
>> that way, maybe I'm missing something?
>
> the obvious choices would be the python wrappers for JACK and/or
> PortAudio.
>
> note, however, that the chances of using Python for per-sample
> processing at low latency without intense dropouts are low.
>
Actually, since Python has an incremental garbage collector,
it should in theory only require replacing the memory allocator with a
real time
memory allocator to make Python pretty hard real time capable. I think.
I also think I remember someone using Python for real time sample
by sample signal processing in Pd...
Efficiency is another story though
I looked into this about five years ago, but didn't get too far. Wondering
if anyone on here has experience splitting apps up into:
- realtime low latency engine in C++ using per sample callback audio (
either RTAudio or Jack or PortAudio )
- user interfaces and algo composition routines in python that either
communicate with the engine by shared memory or over a queue
Basically I want to be able to do the gui and data transforming code in
Python whenever possible and allow plugins to be written to work on the
data in Python
I'm hoping to arrive at some sort of design that ultimately lets the engine
act as an audio server with multiple user interface clients, possibly not
even on the same machines, but definitely not on the same cores. If anyone
has tips, war stories, suggestions on reading or projects to look at, I'd
love to hear them.
Thanks
Iain
Hi!
Well the subject is more technical term of "cutting my favourite show
from radio stream". :D
I guess the usual is to simply define the start and end times and trim
the data to this range.
Pretty straightforward, but in my case nor the start time, nor the show
length is strictly known. My intention is to analyse the data (which
isn't necessarily streaming) to detect signature of show in some way.
Now the case-specific details:
The show I'm interested in is readily recognizable on waveform already.
(see this pic: http://home.venta.lv/s9_smedin_j/files/waveform.png )
The show has an "intro", so I can detect that by "sliding" correlator.
The naive algorithm would be to use one or more sample chunks of this
"intro" and to detect correlation spike when "sliding" and testing
over some range of the larger audio data.
I already started implementation of this, but haven't tested it yet.
Maybe there is good implementation of this? Does phase shift between
sampling positions in test chunk and data skews results significantly?
The end (or duration) of show is a bit more complicated since it is
highly variable. But as can be seen in picture, the end is quite
visible on the waveform and the show has "spikey" waveform since it's
all talking. But I have only very vague ideas how to detect this with a
program. Any ideas on this?
Maybe there is good programs, scripts or LADSPA/LV2 plugins that do
something like this already, which I could use?
Thanks in advance,
JohnLM
