Ken Restivo wrote:
> On Wed, Mar 28, 2007 at 06:23:55PM +0100, Rui Nuno Capela wrote:
>> Hi,
>
>> I thought you'll be curious about some blogging of mine, about my
>> attendance to this year's LAC2007@TU-Berlin, so there it goes:
>
>> - Back from LAC2007@TU-Berlin - The Aftermath
>> http://www.rncbc.org/drupal/node/18
>
>> All photos that I took during my stay can be reached from a small
>> gallery as the same:
>
>> http://www.rncbc.org/lac2007
>
>> Feel free to comment (reg. required though)
>
>
> It looks really thinly-attended.
>
> Looking at this picture, were there really only 30 people there?
>
> http://www.kgw.tu-berlin.de/~lac2007/graphics/WFS-Panorama.gif
>
> -ken
The last ones that remained, yes. But mostly those are the very ones
than ran the whole event. Crew and Authors. And as I noted on my blog
post, most of the audience crowd just went away right after the OLPC
presentation, a couple of hours before that last photo was taken.
Cheers.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I'm writing on a sequencer system based on osc and midi.( No audio )
I'll first describe how it is build up.
As libs I'm using liblo and rtmidi.
The whole app is splitted into different small apps dealing with
specific data.
So there is a timer which has got the main goal to run a loop which
sends an osc message with current tact information.
This msg contains current tact( 0-inf ) the current amount of 192 notes
( eg 45/192 ) and the current amount of 256 notes ( eg 65/256 ).
As a resolution i have chosen 768.
Here is the source code of it.
The function is startet inside a pthread.
iTick is the amount of µsecs the timer has to sleep at the specific bpm
speed.
[CODE]
void Timer::runThread()
{
std::list<Seq>::iterator iter;
timeval tv;
unsigned long startTime, passedTime;
int shortTickCount=0;
int longTickCount=0;
int midiTickCount=0;
while( !bRunning )
usleep ( 100 );
gettimeofday( &tv, NULL );
startTime=( ( tv.tv_sec * 1000000 ) + tv.tv_usec );
for( iter=seqs.begin(); iter!=seqs.end(); iter++ )
{
lo_send_timestamped( iter->address, LO_TT_IMMEDIATE, "/timer/tick",
"iii", iTact, iShortTick, iLongTick );
}
while( !bQuit )
{
if( shortTickCount == 3 )
{
iShortTick++;
shortTickCount=0;
if( iShortTick == 256 )
{
iShortTick=0;
iLongTick=0;
iTact++;
}
for( iter=seqs.begin(); iter!=seqs.end(); iter++ )
{
lo_send_timestamped( iter->address, LO_TT_IMMEDIATE, "/timer/tick",
"iii", iTact, iShortTick, iLongTick );
}
}
if( longTickCount == 4 )
{
longTickCount=0;
iLongTick++;
}
if( midiTickCount == 8 )
{
midiTickCount=0;
midiOut->sendMessage( &midiMsg );
}
shortTickCount++;
longTickCount++;
midiTickCount++;
gettimeofday( &tv, NULL );
passedTime=( ( tv.tv_sec * 1000000 ) + tv.tv_usec );
usleep( iTick-( passedTime-startTime ) );
gettimeofday( &tv, NULL );
startTime=( ( tv.tv_sec * 1000000 ) + tv.tv_usec );
}
pthread_exit( 0 );
}
[/CODE]
The sequencers then play their notes depending on these information.
And of course external midi sequencers play their notes depending on the
midi clock.
So my problem is that this works like crap!
Even if there are no sequencers registered at the timer(seqs.size()==0)
the midi ouput only sends clock messages measuring a speed of ~70BPM.
Although 120 BPM are specified in the app.
And I can't get faster than 150 BPM with the midi clock( internal BPM
would be ~500 )
So I thought it would help to make this thread a realtime thread.
But I found nothing about which scheduling model is currently availabe
for userspace apps and how I append it to the thread.
And I think the sequencers will need a realtime thread for their midi
output, too.
And as I read around a bit I saw that usual system clock is working at
64hz but my loop needs at least 768hz.
Another problem is that I don't know if liblo is fast enough to deliver
the timing messages to usual sequencer clients in realtime.
I found that jack might be useful for me because it supports realtime
threads of usespace apps.
But there might still be a problem with osc.
And there would be a mass of connections in qjackctl then.
So please help me and post anything related that drives and rotates
through your mind.
THANKS for your time reading this!
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF8trPVC26eJ+o0+0RAo/IAJ0eon+tgnNvH+XXn+nYsUFf8IvYJwCbBcjh
EHDn9hFf1VVR2bEqT6twdeQ=
=nMYI
-----END PGP SIGNATURE-----
>From the "debug OSC during lecture talks" dept.
* dump UDP data from a port to stdout
* forward/relay UDP data to one or more UDP ports.
- C source attached - no compile flags needed
The "hacked in Berlin's U-bahn" dept. pre-releases
jplay2 (formerly jadio) - jack-plays-it-all
http://mir.dnsalias.com/oss/jplay2/start
- current Feature cloud:
Open-Sound-Controlled resample JACK-transport vari-speed
scrub-audio ffmpeg libquicktime libsndfile audio-cache
The "no more xruns on app shutdown" dept. has added a few
jack_deactivate() calls to various xj* gj* SVN and git repos.
and finally the "berlin sync-it syndicate" announces it's involvement in
http://ltcsmpte.sf.net
#basically all of it is C-code in progress that I did not consider to be
#releasable software before the LAC2007 ;-) - anyway they're helpers for
#an average day of A/V R&D..
#robin
GMIDImonitor is GTK+ application that shows MIDI events.
New in this release:
* Fix bug causing stalled midi events after burst followed by silence
* Decode jack midi reset message (by Edward Tomasz Napierala)
* Add some instructions about using GMIDImonitor.
Project site:
https://gmidimonitor.bountysource.com/
Screenshot:
https://gmidimonitor.bountysource.com/FileDownload?file_id=50&inline=yes
Source tarball can be downloaded from project site, "Downloads" section
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Jonathan Corbet wrote:
>Dave Phillips wrote:
>
>
>
>>LJ didn't think it worthy enough to fund a reporter's trip.
>>
>>
>
>FWIW, LWN would have been (or would be) more than interested in coverage
>from this conference. And, yes, we can pay for it - as long as you're
>not looking to get rich. There's a lot more than just Slashdot out
>there.
>
Well, we'll know who to ask next year. :)
Btw, is LWN a member of linuxaudio.org ?
Perhaps someone who attended might like to write up something for LWN
re: this year's conference ?
Best,
dp
Hi lists,
my little report on the lac-concerts and some other subjects of the lac
in Karlsruhe will be broadcasted tomorrow on SWR2 JetztMusik Magazin at 23h.
Michael
Hi all,
I have a relatively new setup with a softRAID mobo using dmraid/FC6. One of
the drives have recently began to fail so I had it replaced. However,
rebuilding raid via dmraid remains a mystery to me.
I've rebuilt the array in BIOS and that went apparently well. Still the
second drive has no partitions, yet both BIOS and dmraid report this as "ok"
which it obviously isn't. FWIW, I do hear the second drive doing some
reads/writes but I seriously doubt its integrity.
Should I simply mirror the two drives and then boot into Linux and hope that
this ought to do the trick? I am actually hoping for something more elegant.
BTW, FC6 does have some volume management tools (Gnome) but none of them
give you any options re: rebuilding of the array.
Any help is appreciated!
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology, CCTAD, CHCI
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-1137
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/people/faculty/bukvic/
Hi all,
due to some power renovations in the building of the TU where our server is,
the LAC 2007 site has not been reachable during the past night.
This will last till at least around 14h00 today.
I put the site up at
http://www.nescivi.nl/lac2007/
Also, any emails that were sent in this time to
lac2007(a)robin.kgw.tu-berlin.de, did not get to me.
Please resend to my gmail-address if you sent me mail there.
sincerely,
Marije Baalman
LAC2007 orga team
We are very happy to announce the CLAM 1.0 "Berlin" release while
having splendid views of the Alps in the flight to Berlin for the
Linux Audio Conference.
This release is indeed a major milestone for the project and it
opens a door to the development of exciting new features, so keep
tuned! Apart of these big changes expect also bug fixes (yes 1.0
have bugs) as we move on.
Learn about CLAM in the web: http://clam.iua.upf.edu
Last months have been very positive: many new people showed
interest and contributed in the mailing lists, CLAM got packaged
for almost every Linux distribution, and we got enormous activity
in the svn source repository. We also welcome Andreas as an active
developer and we hope that the forthcoming Google Summer of Code
will also bring new talent aboard.
These are the substantial changes from 0.98:
NetworkEditor (now in version 1.0 like the CLAM libs) let the user
embed any Ladspa plugin in the network as if it was a CLAM
processing. This combined with the fact that you already can
compile a network as a new Ladspa plugin library bringing a new
world of possibilities. Portaudio is now the common stable audio
back-end and its usability have been improved. However, jack is
still taken as the default back-end in linux and osx. The interaction
between Network and its FlowControl have been totally redesigned,
fixing many bugs related with complex network topologies. A new
FreewheelingNetworkPlayer class permits offline execution of
networks, and it comes along with a new binary for command-line
use. At users petition we've also added SMSTools related
command-line binaries. On the signal processing front, we have
added a fftw3 and experimental vowel synthesis processings.
As always, see detailed changes in the change-logs [1]
Find in the download section[2] the usual binaries for Mac OSX
(Intel and PowerPc), Windows, Linux (Debian sid, Ubuntu Edgy and
Feisty) and also new packages for Fedora Core 6 and OpenSuse.
Thanks Fernando, Toni, Paul and others for the great help with
packaging!
The CLAM team
1.
http://iua-share.upf.edu/svn/clam/trunk/CLAM/CHANGEShttp://iua-share.upf.edu/svn/clam/trunk/NetworkEditor/CHANGES
2.
http://clam.iua.upf.edu/download.html
Vamp Plugin API and SDK 1.0 released
====================================
The Centre for Digital Music at Queen Mary, University of London are happy to
announce the 1.0 release of the Vamp Plugin API and software developers kit.
http://www.vamp-plugins.org/
Vamp is a plugin API for audio analysis and feature extraction plugins written
in C or C++. Its SDK features an easy-to-use set of C++ classes for plugin
and host developers, a reference host implementation, example plugins, and
documentation. It is supported across Linux, OS/X and Windows.
The Vamp plugin API is also used by the Sonic Visualiser audio visualisation
and analysis application.
http://www.sonicvisualiser.org/
The development of the Vamp plugin API and Sonic Visualiser was partially
supported by the SIMAC project (http://www.semanticaudio.org/) and the
EASAIER project (http://www.easaier.org/), with assistance from CHARM
(http://www.charm.rhul.ac.uk/).
Chris
