Re: [PD] pix_video not working on Mac OS 10.6 ?
pd extended 0.42.5 Not sure if it was the 64 or the 32-bit version, will have to try that today and report back On Thu, Sep 29, 2011 at 6:24 PM, Hans-Christoph Steiner h...@at.or.at wrote: Which version of Pd? It definitely won't work if you downloaded the 64-bit build. .hc On Sep 29, 2011, at 2:00 AM, rene beekman wrote: I'm having problems getting pix_video to work with the build-in iSight camera on my MacBook. There is no video in the gemwin, just a white rectangle. When I send it a message to open the control panel, GEM hangs (it seems only GEM hangs, I get the beach ball when I hover over the GemWin, but can still move and edit the Pd patch) I've got this on 2 different machines, one 2007 black MacBook and one white 2010 machine. Both run 10.6.8 with latest updates applied. Does anyone else have this problem? Found a solution or even just a work-around? This is coming at the worst of times when tomorrow I need to start teaching a motion capture course... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] sigmund~
Hi, On Thu, Sep 29, 2011 at 06:35:51PM -0700, Benoît Fortier wrote: I'm using the sigmund~ object to get amplitude and pitch information for the loudest peaks of a signal (see the sinusoid-tracking help patch, which can be found in the sigmund~ help patch). Out of that information, I want to create, let's say, 5 midi notes corresponding to the 5 loudest peaks of the signal. How would you transform the peak amplitude outputs of sigmund, which are linear, into midi velocities in order to make those 5 notes sound with the same relative amplitude that they have in the analysed signal? It might be a stupid question but what are those linear peak amplitude values exactly? Do they have any unit? They don't have a unit, they specify the actual peak amplitude of a sine component in a signal. If you feed a sigmund~ with an unscaled [osc~] the peak reported should be close to 1, as the sinewave coming out of an [osc~] goes from -1 to 1, so the absolute peak is 1. If you attenuate this [osc~] by multiplying it by 0.5, sigmund~ should report a peak near 0.5 accordingly. The amplitude is linear in that it directly outputs this multiplication factor - multiplication by constants (homogeneity of degree 1) and addition (additivity) are the two linear operations here. See e.g. http://en.wikipedia.org/wiki/Linear_map for some gory details. There also are non-linear operations possible. For example multiplication of a signal with itself is a first step into the non-linear world. You may remember the parabolic curve if you plot f(x)=x*x which looks like a glass of wine and obviously is not a straight line(ar) anymore. dB-curves are similarily skewed, as are square root, log, or other [pow] curves. Now it's possible to express the amplitude of signals in various ways. The peak amplitude above actually already is a modification in that it only considers the absolute value of the actual amplitude (which is negative sometimes in the case of an [osc~], but not for a [phasor~]!). You could also look at the instantaneous amplitude of a signal with [snapshot~] for example, or calculate some kind of average, or use the absolute peak-to-peak-amplitude (which would be 2 for an [osc~]!) A very important amplitude specification is the RMS or root-mean-square amplitude. This is especially interesting as a signal's power is proportional to the square of RMS. RMS in Pd is calulated by the [env~] object. Now in music you very often are interested in powers, intensities or loudness (more complicated) values, for example you want something to be twice as loud as another sound. That's where logarithms and decibels come in. Check e.g. this http://hep.physics.indiana.edu/~rickv/Loudness_Scales.html for some details. In Pd an important thing to know is its non-standard use of the term dB: For example [env~] outputs values in dB which are scaled so that a [sig~ 1] will have an RMS of 100, and [sig~ 0] has RMS of 0. But to convert these into linear amplitude multipliers from 0 to 1 you cannot just divide by 100, as your intermediate values would be wrong: [sig~ 0.5] gives an [env~] of about 93.97 and not 0.5 as might be expected! Instead use [dbtorms] here, and [rmstodb] for the undo-operation. The attached file shows these operations in action. More reading stuff: http://en.wikipedia.org/wiki/Amplitude http://www.iu.edu/~emusic/acoustics/amplitude.htm Ciao -- Frank dB-and-more.pd Description: application/puredata ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
I actually do switch off everything possible with a spigot but the [receive]s do still need to check if the [send] message is meant to be for them or not. So once you get too many [receive] objects while sending a lot it CAN slow down the patch quite a bit. But unfortunately that only starts showing up once the patch is so big that it takes forever to replace all of the [receive] objects with wired connections. So for now I'm trying to use wires wherever possible to address data only to the object that needs the data rather than having ten thousands of objects checking hundreds of times per second if the data is meant to be for them or not. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Freitag, 30. September 2011 05:04 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? I see... What I do is put a spigot right after all receives and the spigot is controlled by the same messages that control switch~: [r foo] | [spigot 0] | ... In this way you'll at least stop using all lines and metros and the like. I am not entirely sure that having a receive immediately connected to a [spigot 0] has any computational expense, but if I'm measuring things correctly they don't. So no need to shut off receives, just send them to a closed gate best, J On Thu, Sep 29, 2011 at 10:30 PM, Ingo i...@miamiwave.com wrote: Why would you have control messages going if switch~ is off? Because the voice gets assigned to a certain midi channel when it receives a [noteon] and has to keep receiving all midi controllers on that channel until the envelope release has finished. Then the next voice will play on that same midi channel. There is nothing that cuts off the control inlets or [send/receive]s automatically because the audio gets switched off. So when you play 16 notes in a row all 16 voices are set up to receive control data on that particular midi channel. Everything in the control domain, like LFOs, [metro]s and [line]s keep running and keep calculating pitch, volume, filter offsets and so on ... Turning off the [receive]s would be very complicated if not impossible which is why they need to be avoided wherever it can be done. But all of the wired inlets can be cut off manually together with the [switch~] and turned back on when the next note will play that voice. On top of it all 500 parameters need to be updated to the current state of the external control input and the current preset data when played anew. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Donnerstag, 29. September 2011 19:56 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Thu, Sep 29, 2011 at 1:41 PM, Ingo i...@miamiwave.com wrote: One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Why would you have control messages going if switch~ is off? J Ingo - Original Message - From: Ingo i...@miamiwave.com To: 'Roman Haefeli' reduz...@gmail.com; 'Ludwig Maes' ludwig.m...@gmail.com Cc: 'Pd List' pd-list@iem.at Sent: Thursday, September 29, 2011 5:33 AM Subject: Re: [PD] Fwd: Variable number of objects? Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Wed, 2011-09-28 at
[PD] [PD-announce] DEADLINE EXTENDED: Ircam Musical Research Residency 2012-13
(Apologies for cross-postings, French version below) Call for Projects 2012-2013: Musical Research Residency Program Submission Deadline: October 14, 2011 (Midnight Paris Time) Details and submission procedure: http://www.ircam.fr/875.html?L=1 The third edition of Ircam's Musical Research Residency program is now open for online submissions for the 2012-2013 school calendar. Ircam (Institute for Research and Coordination in Acoustics and Music) offers experimental environments where composers/artists strive to expand their artistic experience at one end, and scientists aim at extending research and technological paradigms for new artistic expressions. Such interactive process is called Musical Research. For its third edition, Ircam is inviting composers and artists to submit projects for the 2011-2012 Musical Research Residency program. The program is open to international artists, regardless of age or nationality, who wish to carry experimental research using Ircam's facilities and extensive research environment. Submission is online only and each project will be evaluated by an international panel of experts including researchers, composers, computer musicians and artists. Upon nomination, each candidate will be granted a residency at Ircam during a specific period (three to six months) and in association with a team/project at Ircam. In addition, laureates receive an equivalent of 1200 Euros per month to cover expenses in France. Appel à projet 2012-2013: Résidence de Recherche Musicale Date limite de candidature: 14 Octobre 2011 Plus d'information et procédure de candidature: http://www.ircam.fr/875.html L’Ircam (Institut de recherche et coordination acoustique/musique) offre un environnement unique pour l’expérimentation, permettant aux compositeurs d’étendre leur expérience musicale et de repenser leur pratique à travers les concepts et idées liés aux développements des nouvelles technologies les plus récentes. Ces technologies sont le résultat des défis posés aussi bien par les impulsions artistiques que par les nouveaux domaines de recherche explorés par les équipes scientifiques. À l’Ircam, ce processus interactif est appelé “Recherche musicale”. La troisième édition du programme de résidences de recherche musicale est ouverte aux artistes internationaux, sans condition d’âge ou de nationalité, qui souhaitent conduire un projet de recherche musicale en bénéficiant des facilités matérielles proposées à l’Ircam et de la richesse de son environnement de recherche. Les candidats seront choisis selon un processus de sélection faisant appel à l’expertise de chercheurs et artistes internationaux. Les lauréats vont bénéficier d'une résidence à l’Ircam pour une durée de trois à six mois en lien étroit avec les équipes de recherche de l’Ircam. Le candidat recevra une indemnité forfaitaire équivalente de 1200 euros par mois pour couvrir ses frais pendant sa résidence en France. Arshia Cont Musical Research Coordinator, Ircam - Centre Pompidou. http://mrc.ircam.fr/ ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2011 05:03 AM, Jaime Oliver wrote: I see... What I do is put a spigot right after all receives and the spigot is controlled by the same messages that control switch~: [r foo] | [spigot 0] | ... In this way you'll at least stop using all lines and metros and the like. I am not entirely sure that having a receive immediately connected to a [spigot 0] has any computational expense, it sure has. nevertheless, i usually can be neglected, so i would suggest the same to save some CPU power down the patch. [line] can be become quite expensive when used massively, and a switched-off [line~] that is fed with new values can also make problems (at least it did a while ago; dunno whether this has been fixed) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6FqfoACgkQkX2Xpv6ydvRN6wCfXCWQAedpQOf6CPnpgf99enft jFAAn36dDJYbyTO7ZfIjHYQ40gLqsPB7 =Tu2Z -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Pd-Taipei meeting tomorrow
[image: Pd-Taipei] http://www.flickr.com/photos/honki/6183255759/ Pd-Taipei 是一群喜愛Puredata 的使用者聚會。這次聚會的發起相當特別，是因為旅居英國的藝術家李駿難得回來台灣而發起的聚會，我們期待這次的開始能夠像其他國家的Pd 使用者聚會，例如加拿大蒙特利爾的Pd-Mtl、德國柏林的Pd-Berlin、美國加州的Pd-La 一樣，慢慢有個穩定週期的小聚，讓老朋友與新朋友一起討論、使用Pd 創作並且享受Hack 所帶來的樂趣。 此聚會沒有任何主題，也未安排課程，主要以自學與交流的方式為主。 想知道最新的討論，請訂閱我們的網上論壇 http://groups.google.com/group/openlabtaipei 時間：2011/10/01 星期六 AM11:00 地點：23Design （台北市重慶北路三段25巷3-5號http://bing.com/maps/default.aspx?v=2pc=FACEBKmid=8100where1=103+Taipei%2C+Taiwan%E9%87%8D%E6%85%B6%E5%8C%97%E8%B7%AF%E4%B8%89%E6%AE%B525%E5%B7%B73-5%E8%99%9FFORM=FBKPL0name=23Designmkt=en-US ） Pd-Taipei is set up by a group of Pure Data users in Taipei, which aims to host regular gatherings to create a fun place where people can share their experience and trouble-shoot, just like Pd-Mtl in Montreal of Canada, Pd-Berlin in Berlin of Germany, Pd-La in the California of the United States etc. Sign up today to learn more updates from the link of our online forum http://groups.google.com/group/openlabtaipei Gathering Time: 2011/10/01 Saturday AM11: 00 Location: 23Design (Chongqing North Road, Taipei, No. 25, Lane 3--5) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD-Launch videos + Miller Puckette's 20-lecture puredata video course??
Hi all, Thank you for this precision, Miller. Consequently, Epic and the other interested people, you have the choice ( that sounds good) between probing your patience or misusing this link: http://pd-la.info/2011/04/pd-la-usb-stick/ Au plaisir, Tad Miller Puckette a écrit : Hi all -- There are raw videos (taken by Joe Deken) but they're 30G in total and there are problems with the sound. Joe and Theron Trowbridge have ben working on cleaning them up and compressing them - this turns ou to be a big job. I'm hoping we'll end up with 20 400-ish-megabyte individual files I can host on CRCA, but can't yet make any promises about timing :) Miller On Tue, Sep 27, 2011 at 09:16:31AM -0500, Epic Jefferson wrote: good, please let us know as soon as the videos are uploaded. On Sunday, September 25, 2011, TAD BISAHA tadbis...@gmail.com wrote: Hi the List The answer is described in the attachment. I transfer the videos on vimeo these next days (not before friday) I give you the links in end of this week Au plaisir Tad Epic Jefferson a écrit : I think it's more a question of Miller being ok with the videos being uploaded. On Sun, Sep 25, 2011 at 11:23 AM, TAD BISAHA tadbis...@gmail.commailto: tadbis...@gmail.com wrote: Hi the list I have the videos (USB stick), I can put them on Vimeo or ftp server. But there's a grand question, is everyone of agreement? Au plaisir Tad Darrell Berry a écrit : If there's trivial but tedious work to be done on them, why not upoad them somewhere as data files and let the community do the work? I'm sure many of us would offer some time in return for ongoing access to such a resource...? Julian Brooks jbee...@gmail.com mailto:jbee...@gmail.com wrote: Any real reason why the videos can't go on somewhere like Vimeo for example and upload the patches somewhere too? Seems a rather awkward process. I'm sure lots of people would be interested in checking these out. Particularly if your shipping them 'at cost', why not save yourself lots of bother. I do get the reasoning for doing the usb stick (which look great btw) but a little more open access would be far greater. Cheers, Julian` 2011/9/25 Theron Trowbridge theron.trowbri...@gmail.com mailto:theron.trowbri...@gmail.com mailto:theron.trowbri...@gmail.com mailto:theron.trowbri...@gmail.com Hello, all. The delay on the videos being posted is entirely my fault. We found a (really) minor problem with the videos and I need to fix all of them. But the videos from the sticks exist. The USB sticks are sold though the CRASHspace store, but we don't really do shipping. That being said, anyone who is interested in the videos should e-mail me directly (theron.trowbri...@gmail.com mailto:theron.trowbri...@gmail.com mailto:theron.trowbri...@gmail.com mailto:theron.trowbri...@gmail.com). I have shipped out copies on DVD-R at cost and USB sticks as well. The shipping internationally can get a bit pricey, but I've shipped them around the world, too. I apologize for the delay and any frustration I have caused. We want to get these videos out to everyone. -Theron ^ 2011/9/24 Richie Cyngler glitch...@gmail.com mailto:glitch...@gmail.com mailto:glitch...@gmail.com mailto:glitch...@gmail.com: As far as I can tell that link is for the lectures on a usb stick available if you're in LA. For those of us further away they were going to go up online. I think Theron was working on this. Any updates? I'd be very interested in viewing these lectures too. Thanks heaps On Sun, Sep 25, 2011 at 6:37 AM, TAD BISAHA tadbis...@gmail.com mailto:tadbis...@gmail.com mailto:tadbis...@gmail.com mailto:tadbis...@gmail.com wrote: Bonjour João, Take a look at this address: http://pd-la.info/2011/04/pd-la-usb-stick/ I took this link to acquire a USB. contents: videos + patchs Videos ok, some patchs of examples are missing, but it's of your level, I believe ;-) Au plaisir, Tad Ps: about PdCon last night in Berlin, did you find some cables (4)? jack
Re: [PD] pix_video not working on Mac OS 10.6 ?
As far as I know Pd-extended 0.42.5 32-bit works on Mac OS X 10.6. The 64-bit version does not include Gem. .hc On Fri, 2011-09-30 at 09:12 +0300, rene beekman wrote: pd extended 0.42.5 Not sure if it was the 64 or the 32-bit version, will have to try that today and report back On Thu, Sep 29, 2011 at 6:24 PM, Hans-Christoph Steiner h...@at.or.at wrote: Which version of Pd? It definitely won't work if you downloaded the 64-bit build. .hc On Sep 29, 2011, at 2:00 AM, rene beekman wrote: I'm having problems getting pix_video to work with the build-in iSight camera on my MacBook. There is no video in the gemwin, just a white rectangle. When I send it a message to open the control panel, GEM hangs (it seems only GEM hangs, I get the beach ball when I hover over the GemWin, but can still move and edit the Pd patch) I've got this on 2 different machines, one 2007 black MacBook and one white 2010 machine. Both run 10.6.8 with latest updates applied. Does anyone else have this problem? Found a solution or even just a work-around? This is coming at the worst of times when tomorrow I need to start teaching a motion capture course... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Re : sigmund~
Thanks Frank and Michael. So I understand that linearity of amplitudes in this case and, i guess in many other case as far as pd is concerned, refers to the -1 to 1 scale used to calculate waveform. I do understand the whole idea of linearity and non-linearity but I guess my confusion come from that I tend to see linearity in a relative way. For example, one could say that a linear increase in decidel does not correspond to a linear increase of peak amplitude, and vice et versa (of course). None of the two correspond to a linear increase of the sound that we ear either(as in twice the value = twice the volume).I'll go have a look at all the readings you suggested to me, thanks you again for that. I do remember I've read something about it in Miller's book. Is there anyone else out there using pd to make tools for composers? stuff like spectral analysis that outputs notes in midi format, or tools that transform and modulate melodic patterns in various ways, and then output the result in midi? Thanks again! Benoît De : Frank Barknecht f...@footils.org À : pd-list@iem.at Envoyé le : Vendredi 30 Septembre 2011 3h44 Objet : Re: [PD] sigmund~ Hi, On Thu, Sep 29, 2011 at 06:35:51PM -0700, Benoît Fortier wrote: I'm using the sigmund~ object to get amplitude and pitch information for the loudest peaks of a signal (see the sinusoid-tracking help patch, which can be found in the sigmund~ help patch). Out of that information, I want to create, let's say, 5 midi notes corresponding to the 5 loudest peaks of the signal. How would you transform the peak amplitude outputs of sigmund, which are linear, into midi velocities in order to make those 5 notes sound with the same relative amplitude that they have in the analysed signal? It might be a stupid question but what are those linear peak amplitude values exactly? Do they have any unit? They don't have a unit, they specify the actual peak amplitude of a sine component in a signal. If you feed a sigmund~ with an unscaled [osc~] the peak reported should be close to 1, as the sinewave coming out of an [osc~] goes from -1 to 1, so the absolute peak is 1. If you attenuate this [osc~] by multiplying it by 0.5, sigmund~ should report a peak near 0.5 accordingly. The amplitude is linear in that it directly outputs this multiplication factor - multiplication by constants (homogeneity of degree 1) and addition (additivity) are the two linear operations here. See e.g. http://en.wikipedia.org/wiki/Linear_map for some gory details. There also are non-linear operations possible. For example multiplication of a signal with itself is a first step into the non-linear world. You may remember the parabolic curve if you plot f(x)=x*x which looks like a glass of wine and obviously is not a straight line(ar) anymore. dB-curves are similarily skewed, as are square root, log, or other [pow] curves. Now it's possible to express the amplitude of signals in various ways. The peak amplitude above actually already is a modification in that it only considers the absolute value of the actual amplitude (which is negative sometimes in the case of an [osc~], but not for a [phasor~]!). You could also look at the instantaneous amplitude of a signal with [snapshot~] for example, or calculate some kind of average, or use the absolute peak-to-peak-amplitude (which would be 2 for an [osc~]!) A very important amplitude specification is the RMS or root-mean-square amplitude. This is especially interesting as a signal's power is proportional to the square of RMS. RMS in Pd is calulated by the [env~] object. Now in music you very often are interested in powers, intensities or loudness (more complicated) values, for example you want something to be twice as loud as another sound. That's where logarithms and decibels come in. Check e.g. this http://hep.physics.indiana.edu/~rickv/Loudness_Scales.html for some details. In Pd an important thing to know is its non-standard use of the term dB: For example [env~] outputs values in dB which are scaled so that a [sig~ 1] will have an RMS of 100, and [sig~ 0] has RMS of 0. But to convert these into linear amplitude multipliers from 0 to 1 you cannot just divide by 100, as your intermediate values would be wrong: [sig~ 0.5] gives an [env~] of about 93.97 and not 0.5 as might be expected! Instead use [dbtorms] here, and [rmstodb] for the undo-operation. The attached file shows these operations in action. More reading stuff: http://en.wikipedia.org/wiki/Amplitude http://www.iu.edu/~emusic/acoustics/amplitude.htm Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd-float: rounnding to 1024 points
Hello, why do I get pd-float: rounnding to 1024 points ? (yes, rounnding with 2 n's) gr, Tim ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-float: rounnding to 1024 points
sorry, I was a bit too quick, it seems to be because I used [; wave sinesum 1027 ( instead of [; wave sinesum 1024 ( Wrong assumption on my part, based on the table having to be a power of 2 plus three for sinesum to work... gr, Tim 2011/9/30 tim vets timv...@gmail.com Hello, why do I get pd-float: rounnding to 1024 points ? (yes, rounnding with 2 n's) gr, Tim ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
Le 2011-09-29 à 10:17:00, Jonathan Wilkes a écrit :
Since you have a large patch, I'd be curious to know how much memory is
taken up by having the switched off voices just sitting there.
It's not easy to know how much memory is taken by a bunch of small
mallocs. If you use getbytes() you have some idea of what's going on, but
it doesn't count the malloc accounting info that only malloc()/free()
usually know about, and it doesn't count the overallocation that malloc()
might do in order to make its life easier and make gradual realloc()
faster. Then it also doesn't count the overallocation of the memory zones
so that brk() or mmap() or mremap() doesn't have to be called as often,
which means that when you look at the process size in a process monitor
(ps or top or other) the difference you might see will not be accurate at
all... even if you manage to get it in bytes 4k-blocks instead of
megabytes.
So, if you really want to know the memory usage for a certain part of pd,
make sure that everything uses getbytes() instead of malloc()/new/etc, and
then try to find a formula that can tell you how much extra you should
count, and call it from getbytes() and freebytes() in order to keep
accurate statistics.
E.g. I recall that will the Perl Allocator that was being used by Perl in
the late 90's, you had to add sizeof(void*) to your byte request, and then
round to the next power of two. From this info you can then write :
size_t real_size (size_t n) {return 1highest_bit(n+sizeof(void *));}
highest_bit is a function that finds the position of the highest «1» bit
of an int. I have such a function in gridflow.h :
#define Z(N) if ((xN)(((typeof(x))1N)-1)) { x=N; i+=N; }
static int highest_bit(uint32 x) {int i=0; Z(16)Z(8)Z(4)Z(2)Z(1)return i;}
#undef Z
__
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
Le 2011-09-29 à 19:41:00, Ingo a écrit : One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. I wonder what kind of ears it takes to listen to something so complex... rather, what kind of brain lobes it takes. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
Le 2011-09-30 à 12:01:00, Mathieu Bouchard a écrit :
size_t real_size (size_t n) {return 1highest_bit(n+sizeof(void *));}
erratum :
size_t real_size (size_t n) {return 2highest_bit(n+sizeof(void *)-1);}
because the first version I wrote gets the PREVIOUS-or-equal power, which
is nonsense. Doubling that gives the NEXT power, but not next-or-equal, so
I subtract 1 to compensate for that.
BTW, I haven't looked at modern glibc mallocs. I suspect it might do
things similar to the Perl Allocator nowadays, though I have not checked,
and it's probably not documented (?). Chances are that it's a different
formula, anyway.
__
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Re : sigmund~
Le 2011-09-30 à 08:41:00, Benoît Fortier a écrit : scale used to calculate waveform. I do understand the whole idea of linearity and non-linearity but I guess my confusion come from that I tend to see linearity in a relative way. Yes, linearity is relative, and it can be confusing. But usually, the one called linear is the amplitude ; the square of it is called quadratic ; and the log of it is called logarithmic. If you have a logarithmic scale and call it amplitude, both the linear and quadratic scales have to be renamed to exponential scale, as do all other power scales. Then you can't distinguish them by name anymore, unless you start stating the base. This scheme is self-consistent but not used in practice. C'est tout. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
If you're going to wire them why not just create specific send messages? Give every abstraction an index and send only to that one: [r $1-foo] | etc J On Sep 30, 2011, at 4:13 AM, Ingo i...@miamiwave.com wrote: I actually do switch off everything possible with a spigot but the [receive]s do still need to check if the [send] message is meant to be for them or not. So once you get too many [receive] objects while sending a lot it CAN slow down the patch quite a bit. But unfortunately that only starts showing up once the patch is so big that it takes forever to replace all of the [receive] objects with wired connections. So for now I'm trying to use wires wherever possible to address data only to the object that needs the data rather than having ten thousands of objects checking hundreds of times per second if the data is meant to be for them or not. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Freitag, 30. September 2011 05:04 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? I see... What I do is put a spigot right after all receives and the spigot is controlled by the same messages that control switch~: [r foo] | [spigot 0] | ... In this way you'll at least stop using all lines and metros and the like. I am not entirely sure that having a receive immediately connected to a [spigot 0] has any computational expense, but if I'm measuring things correctly they don't. So no need to shut off receives, just send them to a closed gate best, J On Thu, Sep 29, 2011 at 10:30 PM, Ingo i...@miamiwave.com wrote: Why would you have control messages going if switch~ is off? Because the voice gets assigned to a certain midi channel when it receives a [noteon] and has to keep receiving all midi controllers on that channel until the envelope release has finished. Then the next voice will play on that same midi channel. There is nothing that cuts off the control inlets or [send/receive]s automatically because the audio gets switched off. So when you play 16 notes in a row all 16 voices are set up to receive control data on that particular midi channel. Everything in the control domain, like LFOs, [metro]s and [line]s keep running and keep calculating pitch, volume, filter offsets and so on ... Turning off the [receive]s would be very complicated if not impossible which is why they need to be avoided wherever it can be done. But all of the wired inlets can be cut off manually together with the [switch~] and turned back on when the next note will play that voice. On top of it all 500 parameters need to be updated to the current state of the external control input and the current preset data when played anew. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Donnerstag, 29. September 2011 19:56 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Thu, Sep 29, 2011 at 1:41 PM, Ingo i...@miamiwave.com wrote: One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Why would you have control messages going if switch~ is off? J Ingo - Original Message - From: Ingo i...@miamiwave.com To: 'Roman Haefeli' reduz...@gmail.com; 'Ludwig Maes' ludwig.m...@gmail.com Cc: 'Pd List' pd-list@iem.at Sent: Thursday, September 29, 2011 5:33 AM Subject: Re: [PD] Fwd: Variable number of objects? Actually, I just tried again to simply copy a couple of voices and it only took a fraction of a second with a very short dropout - even with the dsp on. I have recently installed Natty instead of Lucid on a new machine. Maybe it has something to do with realloc that Mathieu mentioned. So it looks like dynamic patching of voices isn't that much of a problem here anymore. It still takes 7-8 seconds to create 16 voices in my case with the dsp off (12 with the dsp on) but that's still faster than restarting the patch. I would never have checked again if nobody would have mentioned it. I have attached a patch that I used for testing. These voices were receiving their input with [receive] so no connections were needed. If you are using wired inlets you will have to dynamically add the connections of course. I added a cut paste at the end because for some reasons the voices didn't get initialized correctly. Not sure if this is needed for other voice-abstractions. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Roman Haefeli Gesendet: Donnerstag, 29. September 2011 08:36 An: Ludwig Maes Cc: Pd List Betreff: Re: [PD] Fwd:
Re: [PD] Fwd: Variable number of objects?
Le 2011-09-30 à 12:32:00, Jaime Oliver a écrit : If you're going to wire them why not just create specific send messages? Yes, that's much faster. But keep in mind that making large amounts of symbols makes gensym become gradually slower, which slows down interpreting $1-foo in all messageboxes, for example. The problem appears gradually as you have several thousand symbols at once, but I have not benchmarked to see how much it changes the balance of things. I think that send/receive will be almost always faster than anything else. [route] is of intermediate speed, faster than [spigot] by a constant ratio for an average of many different lookups. [route] is faster than [spigot] for high indices (right-side outlets), and even faster for lower indices (left-side outlets). [s]/[r] is fast like one of the smallest indices of [route]. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
I wonder what kind of ears it takes to listen to something so complex... rather, what kind of brain lobes it takes. It takes a regular pair of ears - one on the left side and one on the right side! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
If you're going to wire them why not just create specific send messages? Give every abstraction an index and send only to that one: [r $1-foo] | etc J Every [receive] will have to check if any [send] message is meant to be for this particular [receive]. It will have to check if the header of the [send] matches the header of the [receive] until the first character doesn't match anymore. Then it will abort checking and the next [receive] will start checking, and so on ... I can't see how this can be done without taxing the cpu. Having several hundred of messages being sent per second going to several hundred [receives] multiplied by the voice number will add up to many millions of these checks per second. After a certain amount of objects and input data this definitely takes too much time for realtime low latency playing when using high voice counts. It may not affect anything until the number of [send/receive] exceeds a certain number. Getting rid of the [send/receive]s at this point takes a ridiculous amount of time (I'm still not done after several months but getting much better results already). Using dollar arguments only adds a number to the [receive] and doesn't keep it from having to do the checking. That's the reason why I try to avoid [send/receive] objects wherever realtime playing is involved. I still use them, but only for non realtime editing purposes. But there is still a tendency for audio dropouts. Ingo On Sep 30, 2011, at 4:13 AM, Ingo i...@miamiwave.com wrote: I actually do switch off everything possible with a spigot but the [receive]s do still need to check if the [send] message is meant to be for them or not. So once you get too many [receive] objects while sending a lot it CAN slow down the patch quite a bit. But unfortunately that only starts showing up once the patch is so big that it takes forever to replace all of the [receive] objects with wired connections. So for now I'm trying to use wires wherever possible to address data only to the object that needs the data rather than having ten thousands of objects checking hundreds of times per second if the data is meant to be for them or not. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Freitag, 30. September 2011 05:04 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? I see... What I do is put a spigot right after all receives and the spigot is controlled by the same messages that control switch~: [r foo] | [spigot 0] | ... In this way you'll at least stop using all lines and metros and the like. I am not entirely sure that having a receive immediately connected to a [spigot 0] has any computational expense, but if I'm measuring things correctly they don't. So no need to shut off receives, just send them to a closed gate best, J On Thu, Sep 29, 2011 at 10:30 PM, Ingo i...@miamiwave.com wrote: Why would you have control messages going if switch~ is off? Because the voice gets assigned to a certain midi channel when it receives a [noteon] and has to keep receiving all midi controllers on that channel until the envelope release has finished. Then the next voice will play on that same midi channel. There is nothing that cuts off the control inlets or [send/receive]s automatically because the audio gets switched off. So when you play 16 notes in a row all 16 voices are set up to receive control data on that particular midi channel. Everything in the control domain, like LFOs, [metro]s and [line]s keep running and keep calculating pitch, volume, filter offsets and so on ... Turning off the [receive]s would be very complicated if not impossible which is why they need to be avoided wherever it can be done. But all of the wired inlets can be cut off manually together with the [switch~] and turned back on when the next note will play that voice. On top of it all 500 parameters need to be updated to the current state of the external control input and the current preset data when played anew. Ingo -Ursprüngliche Nachricht- Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com] Gesendet: Donnerstag, 29. September 2011 19:56 An: Ingo Cc: Jonathan Wilkes; Pd List Betreff: Re: [PD] Fwd: Variable number of objects? On Thu, Sep 29, 2011 at 1:41 PM, Ingo i...@miamiwave.com wrote: One shouldn't underestimate the cpu load when several hundreds of midi controllers per second are modulating hundreds of parameters and the get multiplied by 16 voices constantly because the control messages are still active all of the time. Why would you have control messages going if switch~ is off? J Ingo - Original Message - From: Ingo i...@miamiwave.com To: 'Roman Haefeli' reduz...@gmail.com; 'Ludwig Maes' ludwig.m...@gmail.com
