Hi all,
I am trying to wrap my head around the OSC interface to FAUST and am trying
to get the noise.dsp from the examples to respond to OSC messages. I have
tried sending it things like "/hello" and "/1/slider1 s 'hello'" and
"/hello f 1.0" on port 5010 while listening on 5011 and 5012 to no avail. I
must be completely missing something here but what exactly am I supposed to
send when it says "a hello message" in the docs? Could someone just go
through all the simple steps of an OSC "hello world" in FAUST?
Kind Regards,
Kaspar
Hi all. Just returned from military services (mandatory period).
It is likely, that i was somehow unsubscribed from list.
In summary, proposed changes are joined in two parts:
1. A few advances for freewheel mode: waiting wheel and per client
free/waiting wheel mode.
2. Get support for any count of "rooms", as they are called in LADISH
therminology, but IMHO, a bit more flexible.
Waiting wheel.
Like freewheel, but doesn't speed up system. When performance is
enough, behave like without any mode (produce sound). And only when it
is not enough, automatically free wheel, until performance is enough
again.
Per client time wheel management.
Clients could be joined into groups, where they have own time flow and
may interact as they are not in free/waiting wheel mode (pass
sound/MIDI each to others).
Other proposals, in two words:
- Ability to change master client (for now it is audio card) on the fly.
- Attaching of audio devices as clients with ability to change driver
and its settings for each (i mean - for all devices; this feature
should go with previous item).
Now about sctucture.
Some components are plugins, which are like LADSPA / LV2 / Other kinds
of audio plugins, but are optimized for use only on JACK (in short,
they are JACK modules).
JACK components:
* single plugin shell (types: plugin host, jack / alsa app) - just to
load other plugins as audio applications, connecting them to other
audio systems, like alsa or other jack instance, like jack app.
* Patchbay (types: plugin host, plugin). Master instance should
be ran by already called plugin shell. Other instances may be loaded
as plugins (making more rooms), or as jack applications. Time wheel
mode changes affect all dependent clients, inluding other patchbays.
* JACK app interface (plugin)
* Adapter for other types of audio plugins (LADSPA, LV2, and
so on). As you can see, such jack implementation may be jack app
itself, and so - it is good to use existing work just as plugin host
(like AMS, Ingen, Jost).
Such jack structure should allow easy implementation of both multiroom
session managers, like LADISH (which is forced for now to implement it
by self) and even allow nested sessions: i'm thinking about universal
modular session manager, which could be used as user session manager,
but also allow nested desktop sessions, and could be expanded by
plugins, adding integration to various systems, like X11 (to manage
windows), jack / alsa (no comments needed) and so on.
It's not clear to me what is legal for an LV2 plugin to do with an input
control port. Once the input port has been read, is it acceptable to use
that location in memory as temporary storage in the "run" method? Is it
the host's responsibility to re-fill the value of the parameter before
every run call? Is it the plugin's responsibility to keep input-ports
bit-exactly the same?
What about transformations of the input which leave the value logically the
same? For example, normalizing boolean inputs the values 0 and 1?
The <http://lv2plug.in/ns/lv2core/#InputPort>
documentation<http://lv2plug.in/ns/lv2core/#Port>is silent on this
matter.
Jeremy
A pretty old and terribly overdue JACK MIDI crash bug as been fixed.
Hopefully at last. Ones who've been using the ALSA-MIDI (aka. ALSA
Sequencer) interface exclusively don't need to worry. All the rest
please apply ;)
QmidiNet 0.1.2 released!
Have fun!
QmidiNet [1] is a MIDI network gateway application that sends and
receives MIDI data (ALSA-MIDI and JACK-MIDI) over the network, using
UDP/IP multicast. Inspired by multimidicast [2] and designed to be
compatible with ipMIDI [3] for Windows.
See also:
http://www.rncbc.org/drupal/node/508
Website:
http://qmidinet.sourceforge.net
Project pages:
http://sourceforge.net/projects/qmidinet
Downloads:
- source tarballs:
http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2.tar.gz
- source package (openSUSE 12.1):
http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2-1.rncbc.suse121.sr…
- binary packages (openSUSE 12.1):
http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2-1.rncbc.suse121.i5…http://downloads.sourceforge.net/qmidinet/qmidinet-0.1.2-1.rncbc.suse121.x8…
Weblog (upstream support):
http://www.rncbc.org
License:
QmidiNet is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
Change-log:
- JACK MIDI in-bound buffering was originally flawed and often the cause
for severe random crashes, mostly due to memory corruption, now
hopefully fixed.
- Changed order of JACK MIDI and UDP socket initialization, hoping the
later is always owned by the current genuine process.
- JACK MIDI interface were sinking all incoming events into the the
first port, now fixed (heads up from Chris Goddard, thanks).
- Make(ing) -jN parallel builds now available for the masses.
- Fixed Makefile.in handling of installation directories to the
configure script eg. --datadir.
- Main context menu simple no-brainer reordering.
References:
[1] QmidiNet - A MIDI Network Gateway via UDP/IP Multicast
http://qmidinet.sourceforge.net
[2] multimidicast - sends and receives MIDI from ALSA sequencers over
network
http://llg.cubic.org/tools/multimidicast
[3] ipMIDI - MIDI over Ethernet ports - send MIDI over your LAN
http://nerds.de
Cheers && Enjoy
--
rncbc aka Rui Nuno Capela
Hey All,
After some very inspiring conversations at the LAC, I have decided to renew
the efforts to document linux audio programming for beginners. I feel that
although there's a lot of really useful tutorials out there, but there's
still a lack of easy accessible introductory audio programming.
Particularly topics such as threading, and thread synchronization are
particularly difficult to learn, or even find relevant, easy to read code
about.
Announcing: Open Audio Programming Tutorials!
This is a documentation effort, not of any particular library or tool, just
"Linux Audio Programming" in general. Feel free to check the code posted,
feedback on it, fork it and send me merge requests, whatever :)
Currently there's 6 different tutorials, all C++ with GTKmm for user
interfaces. Intentions are to add more as time permits!
-Harry
PS: Sending to Linux-Audio-User list in case there's people who want to try
start programming, but haven't subscribed to the Linux-Audio-Developers
list (yet). Replies to Linux-Audio-Developers please :)
>> I have been trying to use GDB to debug this issue.
>> Problem is, as the program crashing is Ingen, I get the information as to
>> where it crashes in Ingen, not where the problem lies in my plugin.
>>
>> Would anybody have any ideas as to how to tacke this issue?
>>
>
> If the plugin runs in a different process,
> it may be necessary to attach that process to gdb.
> Don't forget to compile with debug enabled.
Thanks for that.
I have tried to approach so far:
* gdb --args ingen -eg
I would then run my plugin, remove it, Ingen would crash, but I would
get the information as to why Ingen crashed.
I'm not even sure that GDB would see that it should debug the vco2.so as well
* gdb vco2.so
(vco2.so being the name of my plugin)
Now I start Ingen, get the PID, and use
attach 15674
in gdb (I tried with or without the plugin running).
I get the following error message in GDB:
(gdb) attach 15764B
Attaching to program:
/home/blablack/src/avw.lv2/build/avw.lv2/vco2.so, process 15764
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
I guess GDB is looking for the vco2.so when attaching...
So what stupid thing am I doing?
Thanks in advance for the help,
Aurélien
Guess what...?
the last of the remnants quietly emerges :)
QjackCtl 0.3.9 has been released, finally!
Website:
http://qjackctl.sourceforge.net
Project page:
http://sourceforge.net/projects/qjackctl
Downloads:
- source tarball:
http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.9.tar.gz
- source package (openSUSE 12.1):
http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.9-1.rncbc.suse121.sr…
- binary packages (openSUSE 12.1):
http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.9-1.rncbc.suse121.i5…http://downloads.sourceforge.net/qjackctl/qjackctl-0.3.9-1.rncbc.suse121.x8…
Weblog (upstream support):
http://www.rncbc.org
License:
QjackCtl is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
Change-log:
- Killing D-BUS controlled JACK server is now made optional, cf.
Setup/Misc/Stop JACK audio server on application exit. (a patch by
Roland Mas, thanks).
- Added include <unistd.h> to shut up gcc 4.7 build failures.
- Make(ing) -jN parallel builds now available for the masses.
- A mis-quoting bug at the command line argument string may have been
crippling the (unmaintained) Windows port since ever, leaving its main
function to start jackd dead in the water, belly down :) now hopefully
fixed (following a mail transaction with Stephane Letz and Mathias
Nagorni, thanks).
- Currently a JACK2-only feature, the JACK version string display at the
About dialog box, must now be explicitly enabled on configure time
(--enable-jack-version).
- A new so called "Server Suffix" parameter option appears to rescue on
the situations where QjackCtl falls short on extra, exquisite and/or
esoteric command line options eg. (net)jack1/2 differences.
- Fixed D-Bus Input/Output device parameter settings, filled when either
interface is selected for Capture/Playback only. (probable fix for bug
#3441860).
- Fixed Makefile.in handling of installation directories to the
configure script eg. --datadir, --localedir, --mandir. (after an
original patch from h3xx, thanks).
- Main window is now brought to front and (re)activated when clicking on
the system tray icon instead of just hiding it.
- Add current xrun count to the system tray icon tooltip, if not zero
(after patch #3314633 by Colin Fletcher, thanks).
Enjoy && Have fun!
--
rncbc aka Rui Nuno Capela
Hi everyone,
I posted a new version of the LV2:AVW on the SVN:
svn checkout svn://svn.code.sf.net/p/avwlv2/code/trunk avwlv2-code
Unfortunately, it is crippled with a bug that I can't for the life of me
fix!
The scenario is as followed:
- Open Ingen
- Add one of these plugins
- Remove it and Ingen crashes
That other scenario would crash it too:
- Open Ingen
- Add one of these plugins
- Add any other plugin (I use MDA)
- Remove the MDA plugin, and Ingen crashes.
Now, I don't think the issue lies in Ingen as I can add/remove any
instances of the MDA plugins for example.
But JALV or Ardour don't see to have this issue...
I'm really looking for some help guys, because I have been trying to debug
that one for few weeks now without much success.
Thanks in advance for....anything!
Aurélien
Fons Adriaensen:
> Subject: Re: [LAD] First release of jack_export
> To: Paul Davis <paul(a)linuxaudiosystems.com>
> Cc: Linux Audio Users <linux-audio-user(a)lists.linuxaudio.org>, Linux
> Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
> Message-ID: <20120513125244.GB24479(a)linuxaudio.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Sun, May 13, 2012 at 08:39:18AM -0400, Paul Davis wrote:
>
>> On Sat, May 12, 2012 at 5:09 PM, Fons Adriaensen
>> <fons(a)linuxaudio.org> wrote:
>>
>> > 2. Run jack_export. See --help for options. The --chan option is
>> mandatory.
>> > ? E.g.
>> >
>> > ? jack_export --chan 16 my16channelfile.wav
>> >
>> > ? Jack_export will connect to the 'export' bus if it exists, and
>> print
>>
>> is there a difference between this and
>>
>> jack_capture --channels=16--port=ardour:export/out\*
>> my16channelfile.wav
>
> AFAIK, jack_capture records in real time. Jack_export records while
> Ardour is in freewheeling mode during exporting, so it's usually
> 'faster than real time'.
>
jack_capture can already use the transport system to start and stop
recording,
so adding an option to record during freewheeling shouldn't be very
hard.
> Also, jack_export will ceate a proper WAVEX file (standard WAV must
> not be used for > 2 channels) or CAF, or Ambisonic WAVEX, and provide
> different output formats and optional dithering.
>
jack_capture does that too, except dithering. jack_capture also uses
WAVEX as the default
format for > 2 channels.
Hmm, I might steel your freewheeling and dithering code into
jack_capture. :-)
