sorry for >< please >> <<
We are happy to announce the next issue of the Linux Audio Conference (LAC), May 9-12, 2013 @ IEM, the Institute of Electronic Music and Acoustics, in Graz, Austria.
The Linux Audio Conference is an international conference that brings together musicians, sound artists, software developers and researchers, working with Linux as an open, stable, professional platform for audio and media research and music production. LAC includes paper sessions, workshops, and a diverse program of electronic music.
*Call for Papers, Workshops, Music and Installations*
We invite submissions of papers addressing all areas of audio processing and media creation based on Linux. Papers can focus on technical, artistic and scientific issues and should target developers or users. In our call for music, we are looking for works that have been produced or composed entirely/mostly using Linux.
The online submission of papers, workshops, music and installations is now open at http://lac.iem.at/
The Deadline for all submissions is February 4th, 2013 (23:59 HAST)
You are invited to register for participation on our conference website. There you will find up-to-date instructions, as well as important information about dates, travel, lodging, and so on.
This year's conference is hosted by IEM, Graz, in cooperation with local artists and FLOSS enthusiasts. The Institute of Electronic Music and Acoustics (IEM) at the University of Music and Performing Arts Graz is considered Austria's leading institution in computer music, acoustics and audio engineering and has gained international reputation for its research on spatial audio and its artistic production and research. IEM has been embracing Linux audio as a production and research environment since the mid-1990s, and has contributed to FLOSS/Linux projects, amongst others by providing drivers for multichannel audio interfaces and hosting the Pure Data community portal and mailing lists.
We look forward to seeing you in Graz in May!
Sincerely,
The LAC 2013 Organizing Team
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
I have an array in a subpatch, when I applied graph-on-parent property to the subpatch (to view the array which holds sound so could be fairly large) Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd becames unusably slow to react (sliders, etc.). I was able to solve the problem by removing the graph-on-parent option. So it seems there is something in the interaction of graph-on-parent and the sound engine. this is on a planetCCRMA system: FC17 PD0.42-5extended Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)? Thanks Oded
If I understood your problem correctly, this might be because pd redraws array contents very inefficiently, so if you are constantly changing array contents that can prove quite cpu intensive. Similarly, moving such gop patch requires complete redraw of all its contents. Pd-l2ork fixes latter problem by moving such structures via tag, rather than redrawing everything (so in pd-l2ork moving such gop structure would be one instead of potentially thousands of commands), but the former problem is something that can be only solved by rewriting or getting rid of the networked gui-dsp communication protocol. On Dec 7, 2012 3:43 PM, "Oded Ben-Tal" oded@ccrma.stanford.edu wrote:
I have an array in a subpatch, when I applied graph-on-parent property to the subpatch (to view the array which holds sound so could be fairly large) Pd didn't like that. With dsp off it worked fine but when I turn dsp on Pd becames unusably slow to react (sliders, etc.). I was able to solve the problem by removing the graph-on-parent option. So it seems there is something in the interaction of graph-on-parent and the sound engine. this is on a planetCCRMA system: FC17 PD0.42-5extended Anyone else encounter such a problem? Any solution (beside moving things outside subpatches)? Thanks Oded
______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list http://lists.puredata.info/listinfo/pd-list
If I understood your problem correctly, this might be because pd redraws array contents very inefficiently, so if you are constantly changing array contents that can prove quite cpu intensive.
I don't think that is the problem - I'm not changing the array just load it once the play from it. Thanks Oded
On 12/08/2012 04:18 AM, Oded Ben-Tal wrote:
If I understood your problem correctly, this might be because pd redraws array contents very inefficiently, so if you are constantly changing array contents that can prove quite cpu intensive.
I don't think that is the problem - I'm not changing the array just load it once the play from it. Thanks Oded
In that case, can you try the patch in pd-l2ork to see if it has problems there? Alternately, please post the abstraction/patch and I can test it.
Also, are you experiening problems when you are moving the abstraction around canvas or at all times?
-
IOhannes m zmölnig - LAC 2013 Organizing Team -
Ivica Bukvic -
Ivica Ico Bukvic
-
Oded Ben-Tal