Hi all,
The video recordings of the LAC'14 presentations have just been uploaded
to the conference website and are now directly linked from the archive:
http://lac.linuxaudio.org/2014/program
There are still a three videos missing and the workshop videos are also
yet to come. Currently they are also only available as vp8/vorbis/webm
(sorry IE and Safari users). But since it has been quite a while
already, we decided to not hold back the release of these already
finished videos any further.
Once the collection is complete, we will provide a .torrent. Meanwhile,
for those who prefer to download the videos incrementally, they are
accessible via rsync://linuxaudio.org/ [1].
Many thanks for Frank and Moritz to get those done in really outstanding
quality this year. Kudos to the complete stream-team.
enjoy,
robin - for the LAC'14 team
[1] example to get the 720p versions:
rsync -Pa --exclude "*360p.webm" \
rsync://linuxaudio.org/lac2014/ \
lac2014/
Calling all ChucK’ers, SuperColliders, Max and PureData patchers,
CSounders, Fluxites, Overtoners, and all other tongues of creative
coders. We welcome you to attend the fifth edition of the Creative Music
Coding lab at STEIM.
The CMC lab is an autonomous zone to try out sonic experiments as a
group. And an opportunity to leverage the expertise of the group in
realizing new artistic tools and processes through the medium of code.
Many of the founding members of the group are indeed experts in their
favorite languages, but we come from all technical levels of proficiency
and enjoy helping one-another out.
http://steim.org/event/creative-music-coding-lab-12/
DETAILS
DATE: Tuesday, 24 June 2014
TIME: 19:30
ENTRY: FREE
LOCATION: STEIM Concert Space, Utrechtsedwarsstraat 134 Amsterdam
What ARE the goals for the lab?
* a place for creative music coders to show work in progress, regardless
of programming language or platform
* a place to discuss and question techniques with fellow computer musicians
* an informal stage for playing with others, livecoding sessions,
jamming, and other fun experiments
* an opportunity to meet like-minded artists, share talents, and start
new collaborations
* an opportunity to be exposed to new languages and improve
cross-language fluency
* a way to discover lesser known and emerging creative programming paradigms
* a place to to discuss interconnections between programming environments
* an environment for discussions on cultural contexts surrounding coding
in the arts
We encourage members of the group to use this as a platform for
exploring ways in which we might be able to create and play together.
Proposals for creative group investigations of hardware, software, and
coding as process are welcome.
As always, entry is free, tea and coffee will be provided.
Hello all,
While putting the finishing touches on zita-njbridge and doing a lot
of testing I stumbled on this strange behaviour of jack's frame time.
Let F(i) be the frame time corresponding to the start of period 'i',
and U(i) the corresponding microseconds time.
If jack for whatever reason skips some periods, then one would
expect the difference of F(i) and U(i) to be consistent. They
are in some but not in all cases.
This is the output from a test. When the frame time makes an
unexpected jump, it prints the difference of F, the difference
in U converted to frames, and the difference of these two.
Period size is 256 frames.
dframes = 768 769.0 1.0
dframes = 1024 1322.8 298.8
dframes = 1024 1024.7 0.7
dframes = 768 1067.3 299.3
dframes = 1024 1023.7 -0.3
dframes = 768 1068.5 300.5
dframes = 768 769.2 1.2
dframes = 768 1067.3 299.3
dframes = 1024 1023.9 -0.1
dframes = 1024 1323.1 299.1
dframes = 768 768.2 0.2
dframes = 768 1066.7 298.7
The cases where F and U match are due to starting another client
(designed to be 'heavy'), those where F and U do not match occur
when the same client is terminated (using ^C). The error for
those is consistently a full period plus around 4333 frames.
So it seems that the frame time is not a reliable method to
determine how many frames have been lost.
Using jack1, 0.124.1
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hi everybody
Still recovering from the LAC2014 trip but already with news, here’s the link to our new website (including english version)
www.portalmod.com
The video that was shown at the MOD presentation is right in the frontpage.
Even better, the plugin library can now be navigated in the same way as in the MODs interface. On top of it, there’s a dashboard section where visitors can try the interface without audio.
Hope you all enjoy.
Cheers
Gianfranco Ceccolini
Hi Tim,
that's an interesting point.
Next week I'll be in Pisa, Italy, for a workshop held by some of the
SCHED_DEADLINE guys. I'm not a serious dev but I do research and I'll be
glad to evaluate the benefit of SCHED_DEADLINE for audio and jack,
compared to SCHED_FIFO.
Regards
Leonardo
On 19/06/2014 20:21, linux-audio-dev-request(a)lists.linuxaudio.org wrote:
> since recent kernels provide SCHED_DEADLINE, i'm porting my code to make
> use of it.
>
> * is there any plan to migrate jack1 and/or jack2 to use this scheduling
> policy for the jack thread(s) of the application?
>
> * what is the recommended way to set the scheduling policy of the jack
> thread with the current API? afaict, the JackThreadInitCallback is
> called before JackClient::AcquireSelfRealTime in jack2. (i cannot use
> jack1 due to the old bug that jack corrupts the stack while trying to
> pre-fault it)
>
> thnx,
> tim
--
Dr. Leonardo Gabrielli, PhD student
A3Lab - Dept. Information Engineering
Università Politecnica delle Marche
via Brecce Bianche 12, 60131, Ancona, Italy
Skype: leonardo.gabrielli
Web: a3lab.dii.univpm.it/people/leonardo-gabrielli
<http://a3lab.dii.univpm.it/people/leonardo-gabrielli>
Can anyone recommend something (preferably dead tree form) aimed at those with
some knowledge of the basics?
I've dealt with Yoshimi's "Surface noise" but am struggling with the more
serious refactoring I want to do.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
since recent kernels provide SCHED_DEADLINE, i'm porting my code to make
use of it.
* is there any plan to migrate jack1 and/or jack2 to use this scheduling
policy for the jack thread(s) of the application?
* what is the recommended way to set the scheduling policy of the jack
thread with the current API? afaict, the JackThreadInitCallback is
called before JackClient::AcquireSelfRealTime in jack2. (i cannot use
jack1 due to the old bug that jack corrupts the stack while trying to
pre-fault it)
thnx,
tim
