Hello all,
(Hoping there's SC3 expert on the list)
I haven't been using SC3 for some time, but now I have
to revive some of my work from years ago. As before i'm
controlling it from Emacs.
The current release refuses to run my old code, apparently
because it loads/stores synthdefs from/to
~/share/SuperCollider/synthdefs instead of ./synthdefs.
Re-running all the definitions stores them in the new
place and then things work. But the last thing I want
is to have all synthdefs in one giant heap. They are
always very specific to a particular composition, and
I want to keeo them together with the other files for
each work.
Is there confituration option to make SC3 revert to
the old behaviour ?
More generally, I deeply dislike apps creating
non-specific directories such as ~/share. If SC3
wants a per-login directory it should be ~/.SC3
or something like that.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
Hey gang, is there any good documentation on how to use libsox
on the net? i've been googling but nothing except the ubuntu man
pages cropped up?
------- -.-
1/f ))) --.
------- ...
http://www.algomantra.com
Hi :)
I'm new to the list and I'm not a Linux audio developer. I was a coder
for C64 MIDI and audio, programming in Assembler, I have less knowledge
about C/C++.
Because I have to do some research, e.g. because of strange behaviour of
MTC, I need a MIDI monitor, that shows MIDI bytes instead of an
interpretation of the MIDI events, like it's done by gmidimonitor and
kmidimon.
I just wish to have an application that is reading a timer and byte by byte, so that I can scroll through the MIDI bytes.
START:
001 Is the MIDI client/port ready?
002 If so, get the TIME and the MIDI Byte and write both informations to
an array.
003 If there's pushed a key, jump to STOP
004 If not, go to START
STOP:
A routine that shows the TIMER and MIDI Bytes in a list, that can be
scrolled, maybe simply by saving it as a file.txt.
It should look like this:
minutes:seconds:milliseconds MIDI-Byte
00:00:004 f0
00:00:005 0a
00:00:006 0f
00:00:007 05
Because I need to sync Linux to my Atari ST I was thinking of programming such a MIDI monitor for the Atari in GFA-BASIC and for Linux in X11-BASIC, that nearly is the same BASIC, but I don't know if there is a way to open ALSA MIDI clients/ports for the INP command.
As an alternative I guess I could try to compile and change this source code to my needs: http://www.alsa-project.org/alsa-doc/alsa-lib/_2test_2rawmidi_8c-example.ht…
I know that I have to delete the line numbers, but I don't know how to compile it and what header is needed to be included for using a timer and array.
I need the complete commands or a makefile including the links for the needed libs etc., to compile and link this source code.
Also the changed complete commands or a makefile when I changed the source code using a timer and array.
Or just the MIDI monitor I need.
I don't want to become a developer for Linux, I just want to do researches for bug reports by using a MIDI monitor.
E.g.:
Rosegarden can run as MTC master and sync a Yamaha RX21
Rosegarden can't sync the same way the Atari's Cubase 3.1
Ardour can run as master and sync an Atari Cubase
Another example where definitive is the need to see bytes, is to see if MIDI data is send by running status or not.
Can anybody help me to get such a MIDI monitor, maybe by simply writing me how to compile the rwamidi example?
Cheers,
Ralf
Hello world,
A first edition of the LAC2009 website is now
on line at
http://lac2009.linuxaudio.org
Apart from the initial announcement you'll
find there the calls for papers and music,
and some related documents.
More information will be added in the coming
weeks.
The site is (surprise !) hosted by linuxaudio.org,
site administrator is Robin Gareus, with design
and layout by Christoph Haag.
For the paper submission and review we are again
using openconf, with Frank Neumann at the controls.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
Hi,
A simple message to announce the availability of beta7 of FFADO, the
FireWire audio driver framework for Linux. It took quite some time, but
finally it is ready for large scale public testing.
Release and download information:
http://www.ffado.org/?q=release/beta
Currently, the installation options are:
* manual build from source
* semi-automatic build from source into a 'sandbox'
(http://subversion.ffado.org/wiki/SandboxInstalls)
* APT repository for Ubuntu Gutsy and Hardy (possibly others)
Please test and report issues at our TRAC at http://subversion.ffado.org/
or at the mailing list (ffado-devel(a)lists.sourceforge.net). Please take
note of http://subversion.ffado.org/wiki/WritingGoodTickets when
reporting bugs.
We ask all users of freebob that are not yet testing FFADO to try this
beta release. Note that FFADO can co-exist with Freebob without any
problems, so you can revert back to your original setup very easily.
Enjoy,
Pieter Palmers
ffado.org
Hi,
The linuxaudio.org portal is the official home for Linux Audio
Developers, Linux Audio Users and the Linux Audio Consortium.
There are several other projects that are hosted on the server as
subdomains. In general they work independently of each other and have no
specific theme that is officially mandated.
It is time to change the mandate to have a more general theme or thread
woven into the templates of the various sub domains that identifies the
projects as being part of the portal and reflect the worldwide nature of
the Linux Audio Community.
If anyone has ideas, suggestions or feels creative enough to design a
template that can be used as a basis for the theme we always welcome
your input.
To make it a little more fun we will run a competition for the design.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The competition will be hosted here:
http://lau.linuxaudio.orghttp://quicktoots.linuxaudio.org
You can get a feel for the existing sites by checking out the
linuxaudio.org portal
http://linuxaudio.org/resources
The prizes will be officially presented at the next Linux Audio
Conference where the winners will also be announced.
The Linux Audio Conference 2009
16-19 April 2009
La Casa della Musica
Palazzo Cusani
Parma, Italy
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To start things off Boost Hardware will sponsor $US500 to be distributed
for the prizes. I am also seeking offers of sponsorship from any
businesses that work with Linux Audio software and community projects.
There are a few of you out there so don't be shy. This is a great
opportunity to show your support.
The deadline for submissions will be the 31 Jan 2009. All submissions
will need to be licensed as open source. The official decision for the
winners of the prizes will be made by private vote of the Consortium
board. It will be entirely in the discretion of the Consortium board how
to apply the designs/ideas/templates or concepts that are finally
selected. No members of the consortium board or sponsors will be
elligible for prizes but submissions will still be accepted.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
We will provide more detailed information as the deadline approaches.
--
Patrick Shirkey
Boost Hardware Ltd.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Linuxaudio.org'ers,
It's been a while, and we're behind several announcements..
First of all: linuxaudio.org is doing fine.
Second I'll briefly mention a statement of our Director:
Ivica Ico Bukvic wrote : "We need to start thinking about the function
of the management board. This aspect has been all but dead. How about we
announce restructuring of the board and go from there? My suggestion is
to retain the core of those of us who are most active and then add key
figures in the community who will be active contributors to our cause."
No surprise there. Further discussion may or may not follow on
http://lists.linuxaudio.org/listinfo/consortium/ - and last but not least:
Holger Ballweg has stepped forward and done an amazing job updating
http://apps.linuxaudio.org/. We went on to http://wiki.linuxaudio.org/
which is finally due an official announcement:
* http://wiki.linuxaudio.org
open to public (openID/CAPTCHA)
Everybody is welcome to use this wiki for gnu/Linux and FLOSS audio
related projects or communication. Feel free to ask for additional
permissions or plugins. - send your project application or suggestions
to LAD, start writing a wiki page about it or send a patch ;)
We would like to support maintained and moderated namespaces adopted by
members of the community; balancing http://linuxaudio.org/members in
favor of interest groups. We have neither intentions nor budget to take
on wiki.ubuntu.com or wikipedia. Commercial interest is tolerated.
Professional interest in linux-audio is more or less a prerequisite. The
usual exceptions apply for Music, Art, etc. see http://linuxaudio.org/policy
..and we're not going to stop there.
Here's a quick overview of HTTP services, vhosts and tasks. Any comments
and suggestions are appreciated; as is help getting there:
* http://lad.linuxaudio.org - will be consolidated into drupal
(www.linuxaudio.org) and wiki.linuxaudio.org. - Apart from the
http://lad.linuxaudio.org/events/ (lots of pictures and media) there's
only 16 HTML pages. - similarly lowlatency.linuxaudio.org should become
an entry-point to the wiki.
* http://lad.linuxaudio.org/events/ should be merged with
http://lac.linuxaudio.org
* http://portal.linuxaudio.org, http://linuxaudio.org,
http://lac.linuxaudio.org/
Drupal CMS is edited and maintained by the consortium.
We're urgently looking for 2-5 Content Maintainers (and Guitarists) so
that some of us can take a holiday break.
Besides in the longer term we're looking for volunteers to summarize or
comment on a LAD/LAU thread once in a while, and editors to write short
articles in the likes of kerneltrap.org.
* http://wiki.linuxaudio.org/ is actually the same as
http://apps.linuxaudio.org/wiki/ - vhosts will be merged, redirect..
linuxaudio.org is going to stick to /international english/ for wiki
pages - We'll gladly link to non-english LAO sites - If you're in need
we can provide hosting or bandwidth/mirroring solutions for these.
* http://apps.linuxaudio.org/wiki/request
bookmarklet in beta test. Easy way to submit new apps.
* http://lau.linuxaudio.org and http://quicktoots.linuxaudio.org/
probably remain as is. There are a lot of hidden resources there! -
Maybe some minor updates on the front-page. point to the wiki or portal.
* http://ladspavst.linuxaudio.org/ - great as it is.
* http://ccmixter.linuxaudio.org - for a short time.around
http://www.linuxaudio.org/mailarchive/lau/2007/11/15 we set up a
bare-bone ccmixter.org intended for Music-Made-With-Linux. Should you
desire to style and maintain a ccmixter community: here's your chance.
* http://radio.linuxaudio.org/
Anyone interested? shall we stream random songs from lam.fugal.net ?!
repeat talks from the LAC? or better no-stream than some weird random mix?
* for http://forum.linuxaudio.org/ we started collaboration with
http://linuxmusicians.com/
If you don't like the current style/template: We're challenging
web-designers to come up with a better one.
The consortium-site is a http://drupal.org ; apps & wiki a
http://dokuwiki.org CMS. - get in contact with us on the LAD mailing list.
thanks for your attention,
robin for the linuxaudio.org team.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkkC6XoACgkQeVUk8U+VK0LZ3QCfRoifdS/+k45baQANmAofT1EE
OBMAn3QKOooayPyH1L0YMjfOxCmk8XhB
=zRe3
-----END PGP SIGNATURE-----
Hello all,
Would there be a simple way to import plugin
automation data into an Ardour session ?
'Simple' may include writing some software, but
not any major project :-)
The situation I want to handle is this:
We have a Csound, SC3, PD, program generating
a number of audio signals, and also simple
OSC commands that would control external
processing of these signals, e.g. surround
panning or movement implemented by an
external system.
The signals each become a mono track in Ardour,
while the OSC controlled parameters are stored
as automation data for a LADSPA plugin in each
track. On playback, the plugin just sends this
data to the external application.
The whole point is to combine a number of such
compositions into a single Ardour session that
can be looped without any user intervention.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
On Sat, Oct 18, 2008 at 5:30 PM, Fons Adriaensen <fons(a)kokkinizita.net> wrote:
> On Sat, Oct 18, 2008 at 10:56:31PM +0200, Paul Davis wrote:
>
>> if read_ptr > size then the math should result in the write space being
>> *under* estimated. if thats not happening then my worst nightmares come
>> true, which has happened before. is there a signed/unsigned issue going
>> on here?
>
> The only way to know is to verify all the possible cases in
> jack_ringbuffer_write_space() and jack_ringbuffer_read_space(),
> taking into account that the masking operation may not have
> been applied at the time these are called, and that 'the other'
> *_ptr could be >= size.
>
[Switched from LAU to LAD]
Forget I said anything about context switches. Those don't matter.
The concern here is SMP systems. The bug in the original code is +=
operator used to increment the read and write pointers. That operator
generates the addl instruction, which is not atomic. It needs to be
locked on SMP. The reason Olivier's patch works is because the
increment is done on a temp and then assinged (using plain old =) to
the shared variable. The assignment *is* atomic (since size_t is 4
bytes and presumably aligned to a 4-byte boundary).
I can't prove this right now, but I think I'm correct. That means it
may be possible to make the original code SMP-safe without the
(subtle) change in semantics Olivier's patch makes. Like increment a
temp, store it, mask the temp, store it again.
You can't write lock-free data structures without atomic operations.
While the x86 doesn't need any memory barriers (all stores are seen by
all other CPUs), other platforms could (someone mentioned PowerPC).
The code still needs to be patched for that; just make the x86 version
no-ops.
