Pd-list August 2010

pd-list@lists.iem.at

123 participants
216 discussions

Yet another post about cpu consumption... (for Linux users)
by Pierre Massat 05 Aug '10

05 Aug '10

Hi all! I m running into a problem right that has to do with cpu consumption, but not with GUI. In my live guitar processing patch i use the core of Miller's Phase Vocoder patch for time-stretching. It records bits of what i play and time-stretches them. Now my problem is that it freaks out at times, the sound gets dirty like audio drop-outs, and this is correlated with higher cpu consumption. The thing is that I made my patch as carrefully as i could, that is with minimal GUI and no bangs blinking all the time, and switch~ objects to cut the audio within all the subpatches that are not in use at a certain moment in time. Also, my time-stretching subpatch works fine most of the time, in effect i can use it for two hours in a row without drop-outs. Yet sometimes it just freaks out. So i was wondering, could this be my Fedora desktop that's messing things up? I have Fedora 12, rt kernel, with the standard desktop (which i guess is GNOME?). Would it make sense to try another desktop, like Xfce? I read in a post somewhere that Miller uses a specific desktop which is very light and ideal for work audio work, but i can't find it now. Any advice welcome! Pierre

7 11

Ladi Session Handler
by Cody Loyd 05 Aug '10

05 Aug '10

they used the interface from patchage.. but this does alot more. This application actually allows you to save your connections and running applications as a 'studio' so that you can close everything and then automatically restart all of the apps load appropriate config files and remake all the connections. You can also save and use different jack configs for each 'studio' .. for instance, one that i use for live playing i have configured with low latency, while i have another studio for more complex work where latency isn't a problem, so i set it higher, and i can do more without xruns. On Wed, Aug 4, 2010 at 10:04 AM, Pedro Lopes <pedro.lopes(a)ist.utl.pt> wrote: > Weird I use to call this "Patchage" :) but I guess its the same (or the name > changed). Its pretty useful and more easy to maintain complex connections > than with qjackctl. > > On Tue, Aug 3, 2010 at 10:39 PM, Cody Loyd <codyloyd(a)gmail.com> wrote: >> >> I have just come across a fantastic new application for linux users >> called Ladish. It works as a session manager and frontend for JACK >> and allows users to open and connect multiple JACK applications, and >> then save the configuration so that it can be reopened at any time. >> I've been using it for a couple of days and it is working wonderfully >> for me. In my opinion, this application fills a pretty big hole in my >> Linux music studio. >> It started as a fork of 'LASH' and is already much more useful. >> >> Check it out! This project needs support! >> >> http://ladish.org/ >> >> Cody Loyd >> >> _______________________________________________ >> Pd-list(a)iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list > > > > -- > Pedro Lopes (ongoing MSc) > contact: pedro.lopes(a)ist.utl.pt > website: http://web.ist.utl.pt/Pedro.Lopes >

2 1

Layered Signal Processing and Transport Architecture
by errordeveloper＠gmail.com 05 Aug '10

05 Aug '10

Sorry for being a little bit off-topic, but I would like here from everyone on this list as well as Miller himself, because MAX used to run on a DSP core (according to Wikipedia) This the message that i have posted to alsa-devel list yesturday: I have a proposal for this Layered Model, which would allow implementation of new audio interfaces with DSP cores, with cross-platform compatibility and audio networking in mind. it would be a sort of OSI for signal processing, but with some extra stuff to it, such as a common language (library) for hardware programming. it's not to replace ALSA, but just to bring a different approach for design engineers of professional audio applications. we all know that these days a lot manufactuares chose Linux for their Mixing Consoles (such as Midas, Lawo, Calrec and others), also other products use Linux, but there might be only a few who use ALSA (as far as i could find out there rather NONE in pro-audio Linux devices). Linux runs on devices such as Blackfin and OMAP, which have DSP cores, but the interface is device-specific, hence low-level. ALSA had been designed for conventional sound-cards (largely) also there drivers for RME, DigiGram and other pro-interfaces, but the hardware is still proprietary and it isn't quite flexible. The idea is to bring new concepts to the world, well not 100% new, but new in a way. One of these would be to implement an "open-source" audio processor interface of a kind. It would have configurable channel strips with (multi-band EQ and dynamics). Another motivating factor is upcomming completition of AVB ethernet standard from IETF/IEEE, there had been no publicaly avaliable code for this, nor i could find any discussions of how it could be implemented in Linux. However i have contact with a professor Richard Foss from Rhodes University, and there they have implemented a library and packet generator for AVB, though they haven't yet published this code. There also hasn't heppend any wide adoption of OSC, and may be OSC is not that great? I am currently working on "Control and Monitoring Protocol" which could take part in this architercture on it's TOP Layer. The fallowing are the ABSTRACTION layers that i have thought being most general: ~>> Control, Monitoring and Information (CMI) ACMP (above mentioned above, it's kind of OSC-based) or AES-x170 (both can fit together) also OSC ..or even MIDI but ACMP is more general, it should be good for lighting and other controll applications .. here is the place for GUI interfaces, hardware controllers, control surfaces ...etc ~>> Signal Processing Subsystem (SPS) ~>> Core Signal Bus (CSB) : our inter-connect it has one common clock one or more control ports and one or more signal ports (a port can be input, output, or both) the control ports are exposed to CMI layer the signal prorts can be: bridged (over Ethernet (i.e. AVB), USB or FireWire) interfaced (to say I2S, AES/EBU, AES-50 ..MADI, ADAT) or streamed to a codec or uncompressed file dumping Let's call it an Port Exposure Layer ~>> Core Signal Elements (CSE) the main abstraction for this is library (our cross-platform API) compiler (to produce platform dependent code) interpreter (to configure and glue the blocks) ~>> General Purpose Operating System Of course it is still there ..it could be on a remote machine or anything ..and it could be everywhere around, even General Purpose CPU could be a fall-back option ..well, this is all about abstraction after all :) This is with parallel audio clustering applications and distributed chain processing in mind. Looking forward to here some discussion, I would like to set up a wiki and discusion list for this! Regards, -- Ilya Dmitrichenko Илья Дмитриченко email: errordeveloper at gmail.com

2 2

[solved] Re: Masses of ctlin in abstraction causing CPU Overload
by Christoph Kuhr 04 Aug '10

04 Aug '10

Found the performance thief! Removed a debugging [print]. Now it performs as wanted! Thank you cyrille! Am 04.08.2010 um 15:07 schrieb cyrille henry <ch(a)chnry.net>: > anyway, i think i found a problem. > > in your MIDIctlin abstraction : > whatever midi message received, this abstraction did output the CC > value if port and canal is the good one, but it did output 0 > otherwise. > so a single midi message generate 81 send for each > sendOSCChannelstrip. and you have 8 of them. > > this 648 UDP message are send to both localhost and over the network > (192.168.0.30) > this still did not explain the 20 min wait, but if you use this > version of MIDIctlin, it will greatly reduce problem. > > c > > > Le 04/08/2010 14:44, Christoph Kuhr a écrit : >> well, >> >> i have a main patch (MOD_8) including all the numberboxes and only >> recieving via udp. >> works fine. >> it also calls an abstraction (sendOSCMod_8), which manages all the >> sending: 8 channelstrip (sendOSCChannelstrip) abstractions are called >> with 33 FILTERED(MIDIctlin) [ctlin]. >> calling the sending abstraction alone without the main patch causes >> the >> same problem, and there are no numberboxes in it. >> >> attached the patches >> >> bye >> chris >> >> Am 04.08.2010 14:26, schrieb cyrille henry: >>> hello, >>> what you describe should use a negligible % of CPU. >>> i think there is a problem somewhere. something like a loop with >>> send >>> and receive by example. >>> >>> send your patch to the list so we can have a look. >>> >>> c >>> >>> Le 04/08/2010 14:06, Christoph Kuhr a écrit : >>>> Hi there, >>>> >>>> im working on a digital mixing desk, >>>> any channel is build of 33 MIDI CCs one CPU has to manage 8 >>>> channels >>>> for using ctlin with dynamic arguments, i put it in an >>>> abstraction, did >>>> two multiplications and two compersisons. >>>> when i change a CC value the pd-gui is getting REALLY busy, >>>> computing >>>> about 20 minutes for that one value. >>>> >>>> do you have any ideas, on how to do that more CPU saving? >>>> >>>> >>>> greets >>>> chris >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pd-list(a)iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >> > <MIDIctlin.pd>

1 0

Re: [PD] Masses of ctlin in abstraction causing CPU Overload
by Christoph Kuhr 04 Aug '10

04 Aug '10

Hi again, The hint with that [spigot] is awesome, right what i needed! No more waiting! But the performance is still insufficient... Any further performance tricks? Ck Am 04.08.2010 um 15:07 schrieb cyrille henry <ch(a)chnry.net>: > anyway, i think i found a problem. > > in your MIDIctlin abstraction : > whatever midi message received, this abstraction did output the CC > value if port and canal is the good one, but it did output 0 > otherwise. > so a single midi message generate 81 send for each > sendOSCChannelstrip. and you have 8 of them. > > this 648 UDP message are send to both localhost and over the network > (192.168.0.30) > this still did not explain the 20 min wait, but if you use this > version of MIDIctlin, it will greatly reduce problem. > > c > > > Le 04/08/2010 14:44, Christoph Kuhr a écrit : >> well, >> >> i have a main patch (MOD_8) including all the numberboxes and only >> recieving via udp. >> works fine. >> it also calls an abstraction (sendOSCMod_8), which manages all the >> sending: 8 channelstrip (sendOSCChannelstrip) abstractions are called >> with 33 FILTERED(MIDIctlin) [ctlin]. >> calling the sending abstraction alone without the main patch causes >> the >> same problem, and there are no numberboxes in it. >> >> attached the patches >> >> bye >> chris >> >> Am 04.08.2010 14:26, schrieb cyrille henry: >>> hello, >>> what you describe should use a negligible % of CPU. >>> i think there is a problem somewhere. something like a loop with >>> send >>> and receive by example. >>> >>> send your patch to the list so we can have a look. >>> >>> c >>> >>> Le 04/08/2010 14:06, Christoph Kuhr a écrit : >>>> Hi there, >>>> >>>> im working on a digital mixing desk, >>>> any channel is build of 33 MIDI CCs one CPU has to manage 8 >>>> channels >>>> for using ctlin with dynamic arguments, i put it in an >>>> abstraction, did >>>> two multiplications and two compersisons. >>>> when i change a CC value the pd-gui is getting REALLY busy, >>>> computing >>>> about 20 minutes for that one value. >>>> >>>> do you have any ideas, on how to do that more CPU saving? >>>> >>>> >>>> greets >>>> chris >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pd-list(a)iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >> > <MIDIctlin.pd>

1 0

Ladi Session Handler
by Cody Loyd 04 Aug '10

04 Aug '10

I have just come across a fantastic new application for linux users called Ladish. It works as a session manager and frontend for JACK and allows users to open and connect multiple JACK applications, and then save the configuration so that it can be reopened at any time. I've been using it for a couple of days and it is working wonderfully for me. In my opinion, this application fills a pretty big hole in my Linux music studio. It started as a fork of 'LASH' and is already much more useful. Check it out! This project needs support! http://ladish.org/ Cody Loyd

2 1

pd-extended: error JACK: cannot connect input ports
by Stefan Jensen 04 Aug '10

04 Aug '10

Hi,... i have my brand new "pd-extend" and "jack" running on Fedora 13. Runs fine, but i always have to make the midi connections in jack manually: --cut-- [import] $Revision: 1.2 $ [import] is still in development, the interface could change! compiled against Pd version 0.42.5 Opened Alsa Client 130 in:1 out:1 error: JACK: cannot connect input ports alsa_pcm:Midi-Through/midi_capture_1 -> pure_data_0:input0 error: JACK: cannot connect input ports alsa_pcm:Pure-Data/midi_capture_2 -> pure_data_0:input1 error: JACK: cannot connect output ports pure_data_0:output0 -> alsa_pcm:Midi-Through/midi_playback_1 error: JACK: cannot connect output ports pure_data_0:output1 -> alsa_pcm:Pure-Data/midi_playback_1 libdir loader $Revision: 1.8 $ compiled on Jul 27 2010 at 18:12:41 compiled against Pd version 0.42.5.extended-rc5 GEM: Graphics Environment for Multimedia [...] --cut-- Is that related to my jack config or is there something wrong with my pd config? Thank you Stefan --

3 3

[announce] Integra Live 1.0.0 (beta)
by Jamie Bullock 04 Aug '10

04 Aug '10

Dear Pd list, I am pleased to announce the first public beta release of Integra Live, a new application for the composition and performance of live electronic music. Integra Live uses Pure Data as its signal processing engine and provides a new user interface written in Adobe Flex. The software can be downloaded from the project website: http://www.integralive.org The Adobe AIR runtime is required and can be downloaded from: http://get.adobe.com/air/ Integra Live aims to provide an intuitive and humane interface to advanced signal processing and interaction capabilities. It is currently being developed by the research centres of the Integra project, and will be used by Integra commissioned composers and performers in a series of concerts across Europe in 2011. Please take time to try the software and give us your feedback via the online forum: http://integralive.uservoice.com All best wishes! Jamie -- Dr. James Bullock Senior Researcher, Interactive Technology in Music Performance Software Development Manager, Integra Project Birmingham Conservatoire Birmingham City University UK -- http://www.jamiebullock.com

3 5

pd earthquake notifier
by patrick 04 Aug '10

04 Aug '10

hi everyone, to make story a short story shorter, i am now living in tokyo / japan. this country accounts for about 20 percent of the world's earthquakes of magnitude 6 or greater. so i decided to be updated via RSS using pd / python / gem. the samples are fetched from freesound (randomly using "earthquake" keyword). of course, it's stupid to think that this application will save me. but it was fun to do. http://www.vimeo.com/13615727 pat

3 7

Re: [PD] Masses of ctlin in abstraction causing CPU Overload
by Christoph Kuhr 04 Aug '10

04 Aug '10

thank you! i figured that problem out too, but somehow i didnt realise this as a cpuload problem. but now as you mentioned, it becomes clear!!! have to try this later!... greets chris Am 04.08.2010 14:55, schrieb cyrille henry: > ok, > i don't have all of the OSC stuff, so i can't fully test your patch. > could you provide the minimal version that trigger the problem and > send it to the list (not only to me) > (the list would prefer a zip file) > > c > > > Le 04/08/2010 14:44, Christoph Kuhr a écrit : >> well, >> >> i have a main patch (MOD_8) including all the numberboxes and only >> recieving via udp. >> works fine. >> it also calls an abstraction (sendOSCMod_8), which manages all the >> sending: 8 channelstrip (sendOSCChannelstrip) abstractions are called >> with 33 FILTERED(MIDIctlin) [ctlin]. >> calling the sending abstraction alone without the main patch causes the >> same problem, and there are no numberboxes in it. >> >> attached the patches >> >> bye >> chris >> >> Am 04.08.2010 14:26, schrieb cyrille henry: >>> hello, >>> what you describe should use a negligible % of CPU. >>> i think there is a problem somewhere. something like a loop with send >>> and receive by example. >>> >>> send your patch to the list so we can have a look. >>> >>> c >>> >>> Le 04/08/2010 14:06, Christoph Kuhr a écrit : >>>> Hi there, >>>> >>>> im working on a digital mixing desk, >>>> any channel is build of 33 MIDI CCs one CPU has to manage 8 channels >>>> for using ctlin with dynamic arguments, i put it in an abstraction, >>>> did >>>> two multiplications and two compersisons. >>>> when i change a CC value the pd-gui is getting REALLY busy, computing >>>> about 20 minutes for that one value. >>>> >>>> do you have any ideas, on how to do that more CPU saving? >>>> >>>> >>>> greets >>>> chris >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pd-list(a)iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >>>> http://lists.puredata.info/listinfo/pd-list >>>> >>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Pd-list August 2010