Hey,
Also liking the simplicity, and I think it might be a nice feature to keep
the possiblity to save:
* the studio
* the room
* the project
Perhaps the user could "tagg" each app as what function it has/what its
being used for,
and then allow the saving of all apps with the same "tagg" to a file, for
re-use?
EG:
-name- -tag-
Qsynth piano
JackRack piano (well, its reverb really)
calf piano ( compressor)
and then save tagg piano, and you can reload the same programs?
It does substantially add to complexity I'm aware, but I like the concept of
being able to save subsets of programs and reload them seperatly from the
exact project that they were created in.
It seems a really usefuly feature, get a brilliant piano sound, double click
the file, and your done & playing!
Thats looking from a users point of view. I appreciate that including these
features in JACK might not be the way to go, as its not "core" jack
functionality.
Thought I'd share this idea.. Cheers -Harry
How come the linuxaudio.org mirror (http://download.linuxaudio.org) is not
any more updated with newer releases? Last version available on there is
7.04 which is truly enchant.
What do we need to do to jumpstart this thing again? I presume this would be
something you guys would want to explore, particularly considering that the
hosting/bandwidth are effectively free...
Ico
I wrote a scripting engine for a pro audio plugin by embedding a
CPython interpreter. Since audio sequencing hosts use separate threads
for each audio track, loading more than one instance of my plugin
while running scripting code causes contention on Python's GIl and
results in CPU spikes at low latencies.
While CPython is more than capable of running fast enough in the audio
thread for control-rate (MIDI) work, the GIL is killing us. Using
process migration to move calls to CPython to daemon processes would
take less code than forking python itself, but the scripting engine
includes a python extension module that exposes pointers to the C++
classes in the audio engine. This complicates things quite a bit. The
calls look like this:
size = engine.getAudioBufferSize()
engine.loadPatchFile(SOME_PATH)
instrument.loadAudioFile(SOME_PATH_2)
instrument.setVolume(.5)
...where 'engine' and 'instrument' are C++ classes in the audio engine
that I wrapped in a python extension.
I think that the biggest problem for me is tackling the complexity of
managing new real time daemon processes for each audio track, finding
an IPC method, and also implementing a middle-ware layer that would
allow those synchronous calls to the engine be made back to the host.
This is the sort of overhead that one can expect when trying to use
process migration to work around the GIL. I consider myself an
experienced coder, but just thinking about finding a clean, rock-solid
daemon management and IPC mechanism that works on Mac and Windows
freaks me out.
Does anyone have any comments on this topic?
cheers,
-P
Hi all,
does anyone knows about any Python module for reading incoming MTC
messages? Couldn't find it with a quick google search.
It is not complex to implement, and there are snippets of C code around,
but I'd rather like to not reinvent the wheel.
Thanks,
--
--------------------------------------------------
Pau Arumí
Barcelona Media - Innovation Centre
Av. Diagonal 177, planta 9, 08018 Barcelona, Spain
Phone: +34 93 238 1400
How to edit those pages with content links as :
{{topic>midi_software}}
??
Is that for choosen developers only ?
Maybe related information should be added to
editor_notes (http://wiki.linuxaudio.org/wiki/editor_notes).
Thanks
--
E.R.
Random thought spurred by the "feeds are good" tangent of the LV2
discussion:
It would be really nice to have a Planet LAD (like e.g. Planet Gnome
http://planet.gnome.org/ ). Having these things in your RSS reader
makes it really easy to keep up on what people are up to in general.
I don't know how many blog, but having such a thing would probably be an
incentive to actually do so. Anyone adminney at linuxaudio.org
interested in setting up such a thing? It seems like a straightforward
install assuming Python is available.
Cheers,
-dr
Hey guys,
I've been doing some reading around the internet about Object Orierientated
Program designing,
got a OOP design
book<http://books.google.ie/books?id=KpJQAAAAMAAJ&q=object+oriented+software+des…>,
yet still I'm confused on how to approach designing a "large" program.
That's the background to this question: Is mutex locking the only way to
ensure that variables are only
being accessed by one thread at a time? Is it the "right" way to go about
it?
I've seen quite some strong opinions around the internet on how RT threading
should be done,
however I still am not fully sure if PosixThreads is the way to go, (due to
windows not supporting it).
I've googled for "c++ cross-platform threading" which returned this
post<http://www.codeproject.com/KB/threads/thread_class.aspx>.
I've not yet fully understood it,
but I'm also slightly afraid that Ill be learning a bad habit rather than
how to use a good threading lib!
Any advice on where to start? Cheers, -Harry
JACK 0.117.0 is out. Please see the website http://jackaudio.org/ for
all the details. Many improvements in netjack1 performance, and jack
now runs in realtime mode by default.
The C* Audio Plugin Suite reincarnates as version 0.4.4.
http://quitte.de/dsp/caps.htmlhttp://quitte.de/dsp/caps_0.4.4.tar.gz
CAPS is a collection of LADSPA plugins enjoying worldwide favour for
its instrument amplifier emulation. In addition, it provides a
sizeable assortment of acclaimed audio DSP units, sound generators and
effects. CAPS is distributed as open source under the terms of the
GNU Public License.
-*-
This is a maintenance release, keeping up with g++'s latest whims and
allowing compilation and use on OSX (or so I am told). Other minor
fixes are included but if everything is peachy for you, there's little
need to upgrade. If you're maintaining a CAPS package for your
favourite Linux distribution, it would be a good idea though.
-*-
Enjoy, and thank you for using CAPS,
Tim
Hi,
As Renato mentioned a month ago, the jack-rack-devel list seems to be
inactive, so I am posting this here in case somebody takes an interest
in it.
This is a patch for a few bugs in jack-rack, as of 1.4.7:
1) Specifying the command-line option to autoconnect ports did not work
as j-r tries to connect the ports before it has activated itself.
2) Midi controls for a plugin were not removed if the plugin was
replaced rather than being removed.
3) On/off and wet/dry midi controls, and channel control locking,
weren't loaded properly.
Peter.
