Re: [PD] Problem with tcpserver from iemnet
On Thu, 2012-02-16 at 13:53 +0100, IOhannes m zmölnig wrote: On 02/15/12 23:19, Jack wrote: OK, so if my server quit or crash, I have to wait few minutes (maybe only one) before to relaunch it. I was hoping it was faster. you can also launch the server and keep setting the port to the desired one (using [port 12345( ) until it reports that it is indeed using that port. Ah, I didn't know about that. If I am not mistaken, this part is missing in the help-file. I'll add it. As a work-around, I used to use some bash script to make sure the specified port is free before launching Pd. However, an in-patch solution is _much_ nicer. Cool! Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] socket object?
On Thu, 2012-02-16 at 16:58 +0100, IOhannes m zmölnig wrote: On 02/16/12 16:46, Pagano, Patrick wrote: Hi and thanks We are listening for tcp in max i get the lines read as LaserOutput: [[[2705,246]],[[1358,402]]] and in pd using mrpeach's tcpclient it reads back 91 91 91 50 54 54 49 44 50 56 54 93 93 44 91 91 49 51 54 53 44 52 49 56 93 93 93 13 10 i of course want to strip off the brackets and close brackets and just get to the numbers inside the strings is this possible? Can i convert the bytes to characters/numbers? moocow's pdstring library might come in handy. you could also try to do something like this: [tcpclient ] | [list append 59 10] | [list prepend send] | [list trim] | [udpsend]-[connect localhost ( This won't work, because TCP is a stream-based protocol and you cannot be sure, that the whole _message_ comes in one chunk, or that one chunk contains only one message. It's anyway only mrpeach's [tcpclient] that outputs the incoming stream as chunks (Pd lists). iemnet's [tcpclient] outputs the incoming stream as a stream of Pd floats (which is IMHO the appropriate way). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] unpack type mismatch?
On Thu, 2012-02-16 at 10:23 +0100, Christoph Kuhr wrote: Hi, i route OSC messages an then unpack it. [unpack 0 0 0 0] with one OSC controller i get the error: error: unpack: type mismatch unpacked: 3 14.8743 14.0385 20 with another OSC Controller nothing: unpacked: 3 85.539 85.3286 20 unpacked: 3 15.0827 85.9539 20 why does unpack behave like that? It might be that the controller is sending the numbers as strings instead of floats or ints. [unpackOSC] will then just output them as symbol elements. If that really is the case, you might be able to convert those symbol-numbers to floats with zexy's [atof] which was added just a few minutes ago. Check zexy from svn. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] socket object?
Hi Martin On Thu, 2012-02-16 at 19:53 +0100, IOhannes m zmölnig wrote: On 02/16/12 19:39, Martin Peach wrote: As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets. I think, this is a misconception. As IOhannes pointed out, TCP is a _serial_ protocol. No assumption can be made about the underlying transport. You don't know if an IP packet size can be guaranteed trough the whole path. It might well be, that the at some point the IP packets are broken down in smaller packets. Also the opposite happens easily: When the application sends many small chunks in short time, the network stack might glue them together and put them into one IP packet. There is no way you can take them apart on the receiving side. Also, the application protocols I know that are built on-top of TCP use all some kind of delimiting mechanism (think of HTTP, SMTP, IRC, etc). I don't know of any protocol, that relies on the chunks keeping their size over transport for delimiting messages. Using TCP chunks as a way of delimiting is wrong and should not be promoted (as it is done by the [mrpeach/tcp*] classes). nevertheless, in practice you are right that you will experience problems more easily with large IP packets, and smallish ones (like the ones we were originally talking about) might hardly ever be effected. No, also the smallish ones are affected. See above. I experienced that with Pd. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] socket object?
On Thu, 2012-02-16 at 17:01 -0500, Martin Peach wrote: On 2012-02-16 16:38, Roman Haefeli wrote: Hi Martin On Thu, 2012-02-16 at 19:53 +0100, IOhannes m zmölnig wrote: On 02/16/12 19:39, Martin Peach wrote: As I understood it, the OS's tcp/ip stack will take care of putting tcp packets back together, the application will receive complete messages unless they are bigger than an IP packet (~65k). Only if the sender is dribbling out partial messages would that be a problem. Fragmentation is more relevant to serial communications, where a packet arrives one byte at a time with no obvious boundaries unless you use SLIP, or a serial wireless link where bytes may be lost. TCP just discards broken packets. I think, this is a misconception. As IOhannes pointed out, TCP is a _serial_ protocol. No assumption can be made about the underlying transport. You don't know if an IP packet size can be guaranteed trough the whole path. It might well be, that the at some point the IP packets are broken down in smaller packets. Also the opposite happens easily: When the application sends many small chunks in short time, the network stack might glue them together and put them into one IP packet. There is no way you can take them apart on the receiving side. Also, the application protocols I know that are built on-top of TCP use all some kind of delimiting mechanism (think of HTTP, SMTP, IRC, etc). I don't know of any protocol, that relies on the chunks keeping their size over transport for delimiting messages. Using TCP chunks as a way of delimiting is wrong and should not be promoted (as it is done by the [mrpeach/tcp*] classes). The [mrpeach/tcp*] classes don't make any assumptions about content, they just output lists of floats as they arrive. It seems more efficient to do that than to output individual floats. Whatever is handling the output of a [tcp*] should be able to decide for itself where the packet boundaries are. I don't assume that a list is necessarily the same length as a packet. In practice, it only makes senses to deal with lists instead of single numbers (performance wise) when you don't need to look at the content of the data at all, for instance when you just proxy it to some other receiver (file, comport, netsocket, etc.). However, whenever you need to parse the protocol, you need to serialize the data anyway (since the list length doesn't give you any useful information) and doing that in user-space is much slower than the external doing it on its own. This is the is the case I consider the common one. This is why I still think, that the output shouldn't be lists, but a stream of floats. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Problem with tcpserver from iemnet
Hi Jack Hello Andy and thanx for your answer, I have omitted to write some useful information about my configuration : Ubuntu 11.04 Pd 0.42.6 iemnet [tcpclient] and [tcpserver] compiled on Jan 23 2012 at 12:35:32 I have almost the same setup (Pd 0.43.1, iemnet compiled on 2012-02-02). I cannot reproduce your first problem. Disconnecting clients from the server works fine with your patch here. I tried to close the patch gracefully by disconnecting socket first and then quit Pd after few seconds but when i relaunch both patchs it still doesn't work : it is impossible to connect the client to the server. I have that as well, but it seems it is not specific to iemnet's classes. I experience that with many net classes in Pd and also - IIRC - with other programming languages that provide ways to open a listening socket. On my box it is a matter of seconds until the bind address is freed. On an earlier Debian installation, it was often a matter of minutes (for instance, when the netpd server crashed), which was more annoying. I haven't figured out a way to avoid this. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd extended 0.43-1 nightly missing tk dependency on ubuntu 11.10 (Oneiric)
On Tue, 2012-02-14 at 15:11 -0600, John Harrison wrote: Then that would be the case for all stock Oneirics. I think it should be depends. This will be confusing for novice users, such as those using stock setups. If it would be a 'Depends:', then there wouldn't be a way to install Pd(-extended) without pulling in a whole X-server setup. I think it should stay a 'Recommends:'. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
On Fri, 2012-02-10 at 15:48 +0100, u...@xdv.org wrote: to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off. it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux? Yeah, there is also [disis_wiimote] [1] from the L2ork project. Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix? it still crashes a lot though, especially with With what? Roman [1] http://l2ork.music.vt.edu/main/?page_id=56 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] wiimote report
On Fri, 2012-02-10 at 16:47 +0100, Roman Haefeli wrote: On Fri, 2012-02-10 at 15:48 +0100, u...@xdv.org wrote: to answer my question: i changed onoff from int to float and it works such that i can turn reports on and off. it still crashes a lot though ... well, seems like i should go for supercollider/osc. or is there another wii external for linux? Yeah, there is also [disis_wiimote] [1] from the L2ork project. Since the the wiimote external you were trying is the one that is also included in Debian as pd-wiimote, I think it's worth focusing on fixing this one, since a lot of people would potentially benefit from it. Could you provide a patch for your fix? Hm.. we have clearly more success stories with [disis_wimoote] than with [wiimote] pd-svn. Probably [disis_wiimote] should be in debian? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] precision of vline~ and/or pd messaging
On Sun, 2012-01-29 at 18:30 +0100, João Pais wrote: Hi, another chapter in this: I just tried out the same patch, using now [metro] instead of Lyon's objects. The problem is that the results are still quite simliar, i.e. I still get clicks (almost) every 125ms (the beat duration), resulting from non-aligned phases. You can look at the attached file, get a big zoom, and look at the multiples of 125ms. If you zoom not _that_ deep into it, you notice, that only a small segment of 48 samples (?) has the completely odd phase. The continuing part seems to align fine again. I haven't checked all the clicks, but this applies to the few I checked. Was it supposed that with metro-vline the messages would go out in time, as I understood? The patch is too complicated for me to put it online, so I'll explain what it happens: It's even more complicated to interpret the ongoings without having a look at the patch. - a sound in an array is played in segments of (currently) 125ms - a metro (before Lyon's objects) sends the bangs out - several calculations are made to know which excerpts are played back in the array - the segments get to vline~ in the normal message form: [0, 1 125(, [1, 2 125(, [2, 3 125( (these are fictional values to read three fragments on a sequence) - vline~ goes to tabread4~ Those messages look fine to me, if the expected outcome is that 3 segments of 125ms length at different positions of the table should be played (I think that is what you want). As I understood before, would the metro bangs arrive to vline~ on time, so that vline's reading index doesn't get rebuffered? that doesn't seem to be the case of what's happening now, I think. I also tried changing the message from [0, 1 125( to [1 125(, but there were no differences. Or may I make the final question: is it possible to read table segments sequentially, whose size is different from the block size? Yes. Or does it has to be done with some kind of a polyphonic reader + overlapping? Nope. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] IEM Matrix
Hi Pierre You didn't specify which version and flavor of Pure Data you're using. I assume it's a recent version of Pd-extended. In Pd-extended, for the iemmatrix library to work correctly you need to load two things: iemmatrix and hexloader. I suggest two put the following two objects in your patch: [import hexloader] [import iemmatrix] BTW: This has been extensively discussed on the list. Check the archives for more details. Roman On Wed, 2012-01-25 at 23:31 +0100, Pierre Massat wrote: Dear List, I'm having trouble creating the [mtx_*~] object from the iemmatrix library. I added this library to both Path and Startup in Pd but when i put the object in a patch and quit Pd says it can't create it when i reopen the patch. Is this normal?.. Pierre ___ 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
Re: [PD] a phase vocoder pitch shifter harmonizer in real time
Hi Alex On Mon, 2012-01-09 at 17:28 -0200, Alexandre Torres Porres wrote: get it here: http://sites.google.com/site/porres/pvoc-shifter.zip I wish to officially release it along with some other tools I'm building for my PhD, soon to be over... Cool. Thanks for sharing. Indeed, i find it works quite nice and it has a much lower latency than the pdmtl shifter, for instance. Nice work! Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ring buffer with an array
Hi Alex On Sun, 2012-01-08 at 16:33 -0200, Alexandre Torres Porres wrote: Hi folks, I'm trying to implement a ring buffer with a table for a sampler patch based on an array. But I'm having the hardest time cause it always clicks when I start writing back on the beginning of the array. I made this simple test attached below using metro. But I'm figuring the flaw is because is not trivial at all to keep control data in sync with audio blocks I see two flaws with the same cause in your patch. Both objects, [tabwrite~ ] and [tabplay~ ], execute the incoming messages at block boundaries. Thus, your patch suffers from the limitation that you intended to avoid by not using [bang~ ]. It does not matter whether you use [bang~ ] or not, either way you cannot start the [tabwrite~ ] recording between blocks. It's not possible with the current implementation to make it record exactly every 2000ms (unless 2000ms is an exact multiple of the block size). The same applies to [tabplay~]. It does not take into account the scheduling information of the incoming bang message and simply starts playing at the next block start. Because of above mentioned reasons I suggest to stick with [delwrite~ ] and [delread~ ]. [delwrite~ ] is exactly what you are asking for: a ring buffer. Is there a particular reason why you don't use those? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd Radio
Hi Max On Fri, 2012-01-06 at 15:26 +0100, Max wrote: dear list, i was wondering what current developments with Pd and webstreaming are out there. ... http://radio.rumblesan.com/ I once read about it in irc, when the guy building it had some talks, but missed to actually listen to it. My 1.5 year old son and me really enjoyed it. Thanks for posting this. (It seems at the time of this writing, the stream is offline. I get a 404 when accessing http://radio.rumblesan.com:8000/radio.ogg ) anything else what's notable? It's up to other people to decide if it's notable, but since you're asking, let me mention those in a self-promoting manner: http://195.176.254.176:8010/netpd.mp3 Home: http://www.netpd.org/Listen Plays pre-recorded netpd-sessions in shuffle mode. Stream is generated by a Pd patch. http://195.176.254.176:8010/rsk.mp3 Home: http://www.radiosolarkompass.org/ Plays Radios from all over the world from the those places where the sun currently is rising. Stream is composed by a Pd patch. Cheers Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Detecting audio drop outs inside a patch
Hi all Is there a way to detect DSP drop outs in a patch, respectively to get the information that is displayed in the Pd main window? The idea is to create a [metro]-like abstraction that runs in sync on several hosts. The first problem is getting them in sync, which can be done with a NTP-like protocol. The second problem is keeping them in sync, respectively detecting when an instance loses sync and this is where I am not quite sure how to solve this. One reason for a [metro] to fall behind is an audio drop out. As the information about drop outs is already known to Pd, I would like to know if it is possible to get it into a patch. I thought about measuring the [metro] output with [realtime] in order to detect drop outs. But then I think the maximal allowed deviation without causing a drop out is dependent on the current audio buffer setting and thus this method seems not reliable for detecting drop-outs. BTW: I know about [netro] written by Chris McCormick, but it covers a different use case. It's designed for a setup where all hosts are in the same local network thus it doesn't take network latency into account. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] integer (mis)calculator
Hi Joe Pd uses 32 bit floating point number format which has (as any other number format) some limitations. Not every number can be exactly expressed by this format. '7.1' seems to be such a number. In case you work with only one digit after the decimal point, I suggest to multiply your number inputs by 10 so that they are all integers. Then perform your calculations in this scale. In the end you can downscale your results again with [/ 10]. The reason is that all integers up to 2^23 (or was it 2^24?) can be represented _exactly_ by 32 bit float. BTW: This topic has extensively been discussed several times on this list. You may find more information in the Pd-list archives. Roman On Thu, 2011-12-08 at 00:13 -0800, Joe Newlin wrote: Can someone explain what's going on in the attached example? I'm getting 7.1 minus 7 equals .099. I need to split two-digit integers, so this result is giving me problems. Thanks, JN -- www.joenewlin.net www.twitter.com/joe_newlin ___ 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
Re: [PD] new object: [path] - following the example of [import]
On Thu, 2011-12-01 at 00:21 -0500, Hans-Christoph Steiner wrote: I just added a new object to Pd-extended: [path]. It allows you to append directories to the canvas-local path and have them active immediately. Its basically [declare -path] but with the [import] interface and ability to take effect immediately. Try it in tomorrow's builds and let me know if you think its useful. .hc Wow, thanks! I'll try it out as soon as possible. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] new object: [path] - following the example of [import]
Hi IOhannes On Thu, 2011-12-01 at 11:45 +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hmm, my usual 2 remarks: On 2011-12-01 06:21, Hans-Christoph Steiner wrote: #2 how does this object relate to the quest to eliminate path settings alltogether? i thought -path is really only for nerds like me who feel unable to use standard paths :-) Currently to only way to enable paths relative to patch is using [declare], which does not take immediate effect. As I understand, [path] is supposed to replace [declare -path], so it provides an alternative (immediate) way to load (non-standard) paths. So it helps at least as much as [declare] to eliminate any global path settings and let the patch handle the paths by itself. #3 could anybody tell me why [declare] does not take immediate effect? I'll try to explain the way of how (I think) [declare] works. When you create a [declare] object somewhere in your patch, it just does nothing at all at this moment. Only when you save your patch, Pd will parse the patch and thus look for any [declare] objects and insert right after the first line of the file one additional line per declare object like this: #X declare -stdpath extra/osc; Please note, there is still the original: #X obj 12 72 declare -stdpath extra/osc; line somewhere in the patch, which refers to the actual [declare] object. When loading the patch the next time, Pd will find the '#X declare' line and enable libraries and paths accordingly _before_ the rest of the patch is loaded. This is why [declare] does not take immediate effect. Roman P.S.: This (IMHO, a bit kludgey) way of how [declare] works is also the reason, why abstractions containing [declare] objects pollute the most parent patch, when the latter is saved, which is IMHO a relatively serious bug. Please refer to [1] for more details. [1] http://sourceforge.net/tracker/?func=detailaid=2251387group_id=55736atid=478070 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Findings regarding performance
Hi all Lately I was asking myself if some of own patching practices regarding performance optimization were justified or based on some wrong beliefs. I often use [*~ ] as on/off signal gates and now started be concerned about using an object that performs a relatively complex task (multiplication of two floating point numbers) for such a simple task. I imagined that an object that either outputs a copy of the input or outputs zeros would be a less expensive on/off signal gate than [*~]. I created an abstraction containing this: [inlet~] [inlet] || |[switch~ ] | [outlet~] Let's call this abstraction [gate~ ]. It turned out to work as supposed. But is [gate~] really cheaper than [*~ ]? I made a test by connecting lots of [gate~]s to a chain and measure the CPU usage. For simplicity reason, let's just use an invented arbitrary unit for expressing the CPU time (ct) consumed by an object. It turned out that [gate~] uses 0.52ct when it is on and 0.4ct when it is off. But how much does [*~ ] use? No matter whether turned on or off, [*~ ] uses a stable 0.39ct. The relatively complex multiplication is _not_ more expensive than the on/off implementation with [switch~ ]. Even when turned off, the [switch~] approach is still more expensive. But the really interesting finding comes now. [*~ 0] has only 0.2ct! Almost the the ct value of a plain [*~ ] halved! It also doesn't matter what value the argument has. The plain fact of specifying an argument makes [*~ ] a lot cheaper. I also tested [/~ ], [+~ ] and [-~ ] and the same applies for those. They all have 0.39ct without argument and only 0.2ct with an argument specified. Depending on the kind of patch, this allows for quite a significant performance improvement. I also measured the ct of a [*~ ] when a signal wire is connected to the right inlet. It costs exactly as much (0.39ct) as when sending messages to the right inlet of a [*~ ] without argument. My interpretation is that [*~ 0] and [*~ ] are two different objects. The latter always performs a calculation with two signals and implicitly converts a message on the right inlet to a signal, where the former really only deals with messages on the right inlet (and thus is cheaper). On a completely different note, I wanted to know if it costs anything to have signals entering and leaving subpatches and abstractions a lot, respectively if [inlet~] and [outlet~] add some overhead in CPU time. I chained tens of thousands subpatches together and it seems that does not consume any additional CPU time at all. The values for [inlet~ ] and [outlet~] are much below 0.01ct. I haven't tested the cost, when more than one signal wire are going to an [inlet~], though. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Findings regarding performance
Hi Matju Are you receiving what I write on IRC ? Not always, I think, but I remember the parts you posted below. My question (Is there something more efficient to turn signals on and off than [*~]?) and the things you replied triggered me to do those performance tests. Somehow it is easier for me to deal with stuff that I empirically experience than with written words in IRC where I am not always sure, if I understand the full depth of their meaning. I'm sorry now for not having credited you for bringing me to the topic. Anyway, the fact that you're explaining stuff is not a reason for me to not to make some tests. Howsoever, thanks for your explanations. Roman On Thu, 2011-12-01 at 11:09 -0500, Mathieu Bouchard wrote: Le 2011-12-01 à 15:24:00, Roman Haefeli a écrit : reason, let's just use an invented arbitrary unit for expressing the CPU time (ct) consumed by an object. It turned out that [gate~] uses 0.52ct when it is on and 0.4ct when it is off. But how much does [*~ ] use? No matter whether turned on or off, [*~ ] uses a stable 0.39ct. Even though [switch~] does not use tight conditionals, instead checking only once per block, it still takes some time copying stuff and switching contexts. I suppose that this is the kind of thing that Pd could do more efficiently than it does now, if someone is brave enough to edit d_ugen.c... and knows how to do it. Float multiplications are often so fast nowadays, that the process of reading and writing RAM is often bigger. A lot of machinery in the CPU is dedicated to multiplying floats as fast as possible. But the really interesting finding comes now. [*~ 0] has only 0.2ct! Almost the the ct value of a plain [*~ ] halved! I already explained that on IRC. What part of the explanation was missing ? Here's a copy+paste from the chat. « that's the difference between times_dsp and scalartimes_dsp... the latter is «obviously» faster... well, it does only ⅔ as much data transfer during the perform-function, so it would make sense. benchmarks might say otherwise, or not. _but_ note that sending a float message to [*~] also means copying that value N times (N=block size... 64 or other) whereas in the scalartimes class such as [*~ 42], sending a float (in right inlet) copies that value only once. » and later : « i did not verify it, but it does use twice as much input data. This predicts a possible 3/2 ratio, but there are other reasons why it could be a 2/1 ratio... it depends on the implementation of the cpu itself » « when multiplications are fast, then the bottleneck is to get the data to move around, and if you have twice as much data, it can be twice slower. In some other situations, it can be even worse than twice slower. Those behaviours are harder to understand than ever because optimisation tricks pile up ever more. » I mean optimisation tricks of CPUs and motherboards (caches, RAM chips, etc). __ | 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] Findings regarding performance
Hi João On Thu, 2011-12-01 at 16:04 +0100, João Pais wrote: would it make sense to do a general test patch, where these and more objects could be tested empirically? or, put your patches somewhere, so that other people can work on them, and have a test-repository? I attached my test setup. It's very naive and it doesn't serve much more than to compare different classes on a specific setup (Hardware/CPU, specific Pd version, probably it's even specific to certain compile time flags). main.pd loads many (actually 4096) instances of [gate~]. I simply edited an instance of [gate~] and compared what CPU meter displayed while main.pd was running. On different computers you probably need to add more or remove instances of [gate1024~] in order to get meaningful results. I don't think those patches are worth being included in some test repository, mainly because the results are so much dependent on the specific setup. There is no absolute unit (reproducible on any system) for measuring CPU time, or is there? performance considerations aside, I have a reason to use [*~] with line~, instead of switch~: to avoid clicks (in case there is audio when the chain is broken). I do that as well where applicable. It turns out that [line~] only adds very little overhead when idling (approximately 0.1ct). Of course, it uses more while actually ramping. But you can now test that yourself ;-) Roman Hi all Lately I was asking myself if some of own patching practices regarding performance optimization were justified or based on some wrong beliefs. I often use [*~ ] as on/off signal gates and now started be concerned about using an object that performs a relatively complex task (multiplication of two floating point numbers) for such a simple task. I imagined that an object that either outputs a copy of the input or outputs zeros would be a less expensive on/off signal gate than [*~]. I created an abstraction containing this: [inlet~] [inlet] || |[switch~ ] | [outlet~] Let's call this abstraction [gate~ ]. It turned out to work as supposed. But is [gate~] really cheaper than [*~ ]? I made a test by connecting lots of [gate~]s to a chain and measure the CPU usage. For simplicity reason, let's just use an invented arbitrary unit for expressing the CPU time (ct) consumed by an object. It turned out that [gate~] uses 0.52ct when it is on and 0.4ct when it is off. But how much does [*~ ] use? No matter whether turned on or off, [*~ ] uses a stable 0.39ct. The relatively complex multiplication is _not_ more expensive than the on/off implementation with [switch~ ]. Even when turned off, the [switch~] approach is still more expensive. But the really interesting finding comes now. [*~ 0] has only 0.2ct! Almost the the ct value of a plain [*~ ] halved! It also doesn't matter what value the argument has. The plain fact of specifying an argument makes [*~ ] a lot cheaper. I also tested [/~ ], [+~ ] and [-~ ] and the same applies for those. They all have 0.39ct without argument and only 0.2ct with an argument specified. Depending on the kind of patch, this allows for quite a significant performance improvement. I also measured the ct of a [*~ ] when a signal wire is connected to the right inlet. It costs exactly as much (0.39ct) as when sending messages to the right inlet of a [*~ ] without argument. My interpretation is that [*~ 0] and [*~ ] are two different objects. The latter always performs a calculation with two signals and implicitly converts a message on the right inlet to a signal, where the former really only deals with messages on the right inlet (and thus is cheaper). On a completely different note, I wanted to know if it costs anything to have signals entering and leaving subpatches and abstractions a lot, respectively if [inlet~] and [outlet~] add some overhead in CPU time. I chained tens of thousands subpatches together and it seems that does not consume any additional CPU time at all. The values for [inlet~ ] and [outlet~] are much below 0.01ct. I haven't tested the cost, when more than one signal wire are going to an [inlet~], though. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list perftest.tar.gz Description: application/compressed-tar ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-gui update rate
On Thu, 2011-11-17 at 10:58 -0500, Mathieu Bouchard wrote: Le 2011-11-17 à 15:18:00, Roman Haefeli a écrit : Matju directed me to the respective parts in the source code, but I was not able to make any sense out of it. I said something wrong near the end because I spoke too quick. sched_tick is not a main loop, it's the common part between the big mainloop (ordinary mode), the short mainloop (-batch) and the big callback (-schedlib). The top of that file defines : #define TIMEUNITPERSEC (32.*441000.) which is used by users of sched_tick. That's 14112000 or pow(2,8)*pow(3,2)*pow(5,3)*pow(7,2). 44100 is pow(2,2)*pow(3,2)*pow(5,2)*pow(7,2). 48000 is pow(2,7)*pow(3,1)*pow(5,0)*pow(7,0). Ah.. I was actually looking for the number 14112000, but of course I didn't look for 32. * 441000. But then, 14112000 / 5000 gives 2822.4 Hz, which would be a too high rate for GUI refresh. So, what is relation between the tick and 5000 that leads to a sane GUI refresh rate (and finally, what _is_ the GUI refresh rate)? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-gui update rate
Hi Thanks to Charles, Matju and Miller for your answers. It's somewhat clearer now how those things are working together. In the meanwhile, I made some test. I figured I'd probably be able to determine the refresh rate myself with the help of the nyquist theorem. I made a patch that lets the background color of an iemgui flicker between black and white at a settable rate. Assuming that when I hit twice the Nyquist frequency of the refresh rate (which equals the refresh rate) the visible flicker frequency should go towards zero, which means the slider should stay black or white. Apparently, this happens when I set the [metro] to 8.3 ms. The actual period is twice that, because I need a metro tick for the white and one for the black phase. So the whole period amounts to 16.ms which corresponds to 60 Hz, which is the refresh rate of my screen. Somehow I was always assuming that Tk (at least in Pd) is rendering slower than that. Don't know why I believed in that myth. Actually, I like being able to use the full speed of my screen in Pd. Yet, in many patches I often artificially limited GUI refreshs to 20 Hz, assuming that higher rates wouldn't be displayed anyway. Wrong! Thanks! Roman On Fri, 2011-11-18 at 09:41 -0800, Miller Puckette wrote: There's no fixed update rate, but Mahieu is right, Pd polls for the ability to make an update every DSP tick. (one is able to do an update if the socket from Pd to GUI is writable, i.e., not full). I've thought for a long time about putting an explicit throttle (on the order of 5-10 msec) or a flow control mechanism (passing round-trip tokens through the GUI to see when things are actually getting updated) but have put this off because of more urgent problems :) M On Fri, Nov 18, 2011 at 11:48:25AM -0500, Mathieu Bouchard wrote: Le 2011-11-18 à 09:34:00, Roman Haefeli a écrit : Ah.. I was actually looking for the number 14112000, but of course I didn't look for 32. * 441000. But then, 14112000 / 5000 gives 2822.4 Hz, which would be a too high rate for GUI refresh. So, what is relation between the tick and 5000 that leads to a sane GUI refresh rate (and finally, what _is_ the GUI refresh rate)? Oops ! sched_tick handles the span of time of one hardware dsp block, and I think that this is usually frozen to be 64 samples regardless of sampling rate (for 44100 Hz, this is 1.45 ms). the while() loop looks for all upcoming clock events ([metro], [delay], [pipe], etc) and processes them until the time of the next dsp block. The 5000 might be never used. You'd need 5000 [metro] or [delay] objects being activated between two consecutive dsp blocks. In addition to being very unlikely, it's also nearly impossible to do : if 5000 objects put 5000 things in the clock queue in chronological order, this takes 12.5 million loops per clock tick, and each loop is 3 comparisons and 2 assignments. No CPU has the time to do it in one tick. Pd doesn't have to be like that, there are good datastructures that it could use, but it does not use them, so it's extremely inefficient at some things when those things appear in large numbers. You can get well over 5000 clock activations in one dsp tick, but you have to do it in other ways. you need a self-connected [delay] with an extremely low number, because [metro] won't let you make a [metro] that fast. Anyway, I don't get it, I mean I don't get the existence of the 5000. My previous answer about 14112000 was a mistake : the number is correct but unrelated. Instead, sys_pollgui is called almost only from m_pollingscheduler... It looks like it's called at every dsp tick (1.45 ms) but inside sys_pollgui it calls sys_domicrosleep which is actually a function that checks all filehandles for incoming data, and if there's no incoming data in a given tick, then sys_poll_togui is called. That one, in turn, checks whether the output buffer is empty, and if it isn't, then it doesn't call sys_flushqueue. So, the answer seems like it's that pd refreshes the gui using a clock of 689 Hz, and the fastest possible GUI updates would be half of that, but Tcl never keeps up with that, so it slows down the rate by just not reading enough stuff that pd sends it, and pd skips calls to sys_flushqueue in those cases. __ | 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-gui update rate
On Fri, 2011-11-18 at 18:53 +0100, András Murányi wrote: Lame question: Would user-settable GUI refresh rate help with speed problems or with audio dropouts that some people experience? Or do these depend on the amount of data transmitted and not on the update frequency? I _think_ this depends on the kind of GUI element. If you send thousand messages per second to a slider, then it would probably help. But you can limit the rate already now, so I personally don't think that a fixed refresh rate would urgently be necessary. I think arrays can be quite a hog since not only for every pixel you see a message from pd to pd-gui was sent, but for every sample. This can be quite a lot of messages when you change significant chunks of an array. However, a fixed GUI refresh rate wouldn't help with this. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, 2011-11-17 at 13:14 +0100, katja wrote: On Thu, Nov 17, 2011 at 2:43 AM, Jonathan Wilkes jancs...@yahoo.com wrote: Are there Pd attributes other than version and dsp status that would be nice to make gettable? Very useful! I could think of these, to start with: [; pd get tcl-version rcv-name( sends tcl-version $ to rcv-name [; pd get float-precision rcv-name( sends float-precision $ to rcv-name (expressed as 8*sizeof(t_float)) [; pd get pd-path rcv-name( sends pd-path path/to/pd to rcv-name To complement the last one (in the syntax proposed by IOhannes): [; pd get rcv-name start-path( Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, 2011-11-17 at 14:53 +0100, Patrice Colet wrote: Hello, would this method provide patch window size and position? [; pd get size pd-mpatch.pd rcv_name( [; pd get pos pd-mpatch.pd rcv_name( How would pd know which canvas you mean? Wouldn't it make more sense to ask the canvas itself instead of pd? pd-canvasname is already listening for stuff... Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd-gui update rate
Hi all I would like some GUI elements in a patch to refresh with the highest rate possible, but at the same time also as economic (in terms of CPU usage) as possible. How can I know at which rate a Pd canvas is updated so that I can adjust the gui update accordingly? Matju directed me to the respective parts in the source code, but I was not able to make any sense out of it. I've come so far yet: In src/m_sched there is 'void sched_tick' which (afaict) runs the 'while' loop that runs the whole Pd DSP and GUI stuff. It seems that every 5000 clock ticks, the whole GUI is refreshed (sys_pollgui()). But how long is such a tick? Can someone make more sense out of it? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] get method for Pd
On Thu, 2011-11-17 at 15:12 +0100, IOhannes m zmoelnig wrote: On 2011-11-17 15:07, Jonathan Wilkes wrote: I think that belongs in the canvas get method: [; pd-mpatch.pd get etc.( what would that return if you have multiple instances of the mpatch abstraction? I think the most natural behavior would be that all instances would respond in an un-orderer manner. If you want to request many instances separately, you'd have to use something like [namecanvas]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Troubles running Pd-0.43.1test5 on Windows XP
On Tue, 2011-11-15 at 23:55 +0100, Roman Haefeli wrote: Hi Miller This is on Windows XP Pro / Version 2002 / SP3 32bit in a VirtualBox VM. It really only happens with Pd-0.43.1test5, but not with Pd-0.43.1test4 or any earlier version. Now I have tried it on another VM-machine with the same OS Version and I can start Pd-0.43.1test5 there. Something is special about the first machine, but I don't have the slightest idea what. It's a plain OS install with all updates applied and then Pd installed. Yet we have two reports where it is working on Windows XP. Could that be related to my version being Pro (I don't know about the specifics of 'Pro') or to the fact that it is in a VM? Apparently, it's neither. Since yet it is only this (my) box with this problem, I'm sorry for having made so much noise. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Troubles running Pd-0.43.1test5 on Windows XP
Hi Miller This is on Windows XP Pro / Version 2002 / SP3 32bit in a VirtualBox VM. It really only happens with Pd-0.43.1test5, but not with Pd-0.43.1test4 or any earlier version. Yet we have two reports where it is working on Windows XP. Could that be related to my version being Pro (I don't know about the specifics of 'Pro') or to the fact that it is in a VM? I'll try to find another Windows XP installation... Roman On Mon, 2011-11-14 at 11:51 -0800, Miller Puckette wrote: What version of Windows did it fail on? I switched versions of Tcl/TK for 0.43-1 (someone else on the list suggested this to solve some other problem I think) - which could easily be the source of the trouble. But I need to be able to make it fail so I can fix it :) Miller On Sun, Nov 13, 2011 at 10:54:15AM -0500, Martin Peach wrote: I just tried it now and it seems to work fine. Martin On 2011-11-13 10:40, Roman Haefeli wrote: Hi all Has anyone tried to run the last release of Pd (Pd-0.43.1test5) on Windowx XP? I fail to even start it. Double-clicking either pd.exe or pd.com does just nothing. When calling pd.com from the cmd shell, I get this output: C:\pds\pd-043.1test5\binpd.com spawnl: Invalid argument C:\pds\pd-043.1test5\bin\wish85.exe: couldn't load TCL Is it only me, or is this release really broken on Windows XP? Roman ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-1 test 5 released
On Fri, 2011-11-11 at 11:05 -0500, Hans-Christoph Steiner wrote: On Nov 11, 2011, at 7:58 AM, Roman Haefeli wrote: Sorry for this vague bug report. I thought it's better to mention it even when I cannot provide enough useful information yet. Can you reliably reproduce the bug? Having a complicated patch with steps to reproduce the bug every time is still helpful. If the bug is intermittent, have you confirmed that it really doesn't happen in test4? In the meanwhile I posted a proper bug report: https://sourceforge.net/tracker/index.php?func=detailaid=3437312group_id=55736atid=478070 Yeah, it happens every time and it is indeed only happening on test5, but not on test4. Luckily, the patch to trigger the crash is not so complicated anymore. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Troubles running Pd-0.43.1test5 on Windows XP
Hi all Has anyone tried to run the last release of Pd (Pd-0.43.1test5) on Windowx XP? I fail to even start it. Double-clicking either pd.exe or pd.com does just nothing. When calling pd.com from the cmd shell, I get this output: C:\pds\pd-043.1test5\binpd.com spawnl: Invalid argument C:\pds\pd-043.1test5\bin\wish85.exe: couldn't load TCL Is it only me, or is this release really broken on Windows XP? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-1 test 5 released
Hi Matju On Sun, 2011-11-13 at 12:56 -0500, Mathieu Bouchard wrote: On Sun, Nov 13, 2011 at 03:58:41PM +0100, Roman Haefeli wrote: In the meanwhile I posted a proper bug report: https://sourceforge.net/tracker/index.php?func=detailaid=3437312group_id=55736atid=478070 Is Valgrind reporting its first Invalid Write in the same spot, or not ? Why are you asking? Are you going to help fix this? Can you also post Valgrind backtraces for all the Invalid Writes ? How does it help to also have the Valgrind backtrace? Unfortunately, I'm not familiar with Valgrind. Probably you could give me a hand with it or even create the backtrace yourself (?). I think I posted all the necessary information to make Pd crash. Perhaps even any related warnings (but note that Valgrind always provide a bunch of unrelated warnings). Is it something like that it considers Pd's symbol table to be a memory leak because it gets never freed as long as Pd is running? I'm not sure, but I vaguely remember you saying something the like. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-1 test 5 released
Hi Miller On Sun, 2011-11-06 at 22:55 -0800, Miller Puckette wrote: Another test version... I still am working on 2 bugs. The biggest change is that I updated tcl/tk to version 8.5 in the Windows compiled package. It's on the usual http://crca.ucsd.edu/~msp/software.htm or: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data It seems that test5 is crashing in certain circumstances during patch editing, where test4 is not crashing under the exact same circumstances. What happens is that when I change the arguments of a certain abstraction and the click to the empty canvas to let it re-instantiate with the new arguments, Pd segfaults. Also, when editing that said abstraction (many instances are used in the patch) and then saving it, Pd segfaults. Since this happens in a not so small project, isolating the problem and creating a small test patch could be quite time consuming. Would a gdb traceback already help to track it down? This on Ubntu 11.04 with Pd-0.43.1test5. Sorry for this vague bug report. I thought it's better to mention it even when I cannot provide enough useful information yet. Roman ___ 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] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
Hi Ingo On Thu, 2011-11-10 at 13:10 +0100, Ingo wrote: Hi everybody, I need some help about sample rate settings. I would like to use my SPDIF Out with Pd. Unfortunately it looks like either the soundcard or the audio system (OSS) starts up with 48,000 Hz while Pd is set to use 44,100 Hz (that's necessary because of the samples being at 44.1k). Does anybody know where or how I can set the PCM sample rate to match Pd's sample rate? None of the soundcard mixers I was checking have an option to set the sample rate and I don't know where the OSS files are located. I don't know about your soundcard, but many (cheap) soundcards only support 48kHz. You probably won't notice it with ALSA, since ALSA is capable of resampling the sound before pushing it to the card, but if you really are using old-school OSS, I think there is no way to resample. Just in case, you're sound card really only supports 48kHz, would resampling your audio files be an option? At least then you have some control over the resampling quality. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Natty SPDIF samplerate 44.1k / 48k problem (OSS)
On Thu, 2011-11-10 at 17:14 +0100, tim vets wrote: .. Lastly: I wonder if there isn't a way to downsample some subpatches to playback the 44.1kHz soundfiles in a 48kHz environment? Why would you want to run an [osc~ 440] at a different samplerate, when it plays a 440Hz anyway? Regarding audio samples, you can use [tabread4~] fed by a [line~] instead of [tabplay~] for up- or downsampling. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 17:54 -0400, Mathieu Bouchard wrote: Le 2011-11-03 à 21:09:00, Roman Haefeli a écrit : And it does not make so much sense to compare Pd/Max to anything outside of Pd/Max. Why ? You said (as it is like with any string-splitter outside of pd/max). I should have said it more precisely: It doesn't make sense to compare Pd/Max with anything outside of Pd/Max regarding string-splitting, because 'just' splitting symbols (without the implicit conversion to float for number-like symbols) is not very practical in the Pd/World. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Interruption of audio / Loading sound into array
On Fri, 2011-11-04 at 11:26 +0100, katja wrote: By coincidence I noticed an svn commit access request from Damian Stewart, back in 2008, where he proposes to 'implement multithreaded [soundfiler] read' (http://lists.puredata.info/pipermail/pd-dev/2008-12/012447.html). What has become of this? Is there any code from this project? [readsf~] and writesf~] are threaded, they operate in a child process. I guess it could not be otherwise? Because they do not intend to read all samples at once. Looking at the code in d_soundfile.c, I can understand why the whole of Pd should not be multithreaded. It is a lot of overhead. But [soundfiler~] read is another exceptional case indeed, it needs carefully scheduled loading if it is not to cause buffer underruns elsewhere. Such loading in portions would also mean the whole audiofile is not immediately available in memory. Therefore, the result would somehow be equivalent to the '[readsf~]-in-an-upsampled-patch' trick. The problem with the '[readsf~]-in-an-upsampled-patch' approach is that you cannot know how fast you can do it without interrupting audio. Also you cannot really fine-tune it since you can only set it to a speed to any power of two. Ideally, a threaded [soundfiler] would load the file as fas as possible in the background without interfering with Pd's main process and then it would output a bang when done. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 10:51 -0400, Mathieu Bouchard wrote: Le 2011-11-03 à 09:20:00, IOhannes m zmoelnig a écrit : On 2011-11-02 18:06, rolf meesters wrote: would it then be necessary, working with texts, always to check if one's not accidentally losing zero's? btw, you are not losing any zeros. whether your pay cheque says 100,-€ or 100,-€ does not make any difference, when it comes to buying your marmite. those numbers are exactly the same. And this is exactly not what Rolf is talking about. Surely you know the difference between string comparisons and number comparisons... If someone just wants to split lists instead of converting to floats and getting weird answers on pd-list, there's [gf/s2l], which does not do anything else than splitting (as it is like with any string-splitter outside of pd/max). Yeah, and currently there is no way really to tell Pd whether something should be of the type symbol or float, so the fact that it assumes anything that looks like a number to be float makes sense (you can still force numbers to be symbols as few already suggested). And it does not make so much sense to compare Pd/Max to anything outside of Pd/Max. [symbol2list] behaves pretty sensible in its context, as pretty much anything in Pd converts 00023.1 or 23.10 to 23.1. Calling the previous answers 'weird' is inappropriate, IMHO. (BTW, I'm not saying I favor Pd's limited type casting capabilities) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 08:33 -0700, Jonathan Wilkes wrote: From: Mathieu Bouchard ma...@artengine.ca If someone just wants to split lists instead of converting to floats and getting weird answers on pd-list, there's [gf/s2l], which does not do anything else than splitting (as it is like with any string-splitter outside of pd/max). Once split, is there a way to convert symbol-atom 19.95 to a float? Two work-arounds come to my mind: 1) Send the symbol to [textfile] save it as a file, read the file again and output the result. 2) Send it through a [netsend] / [netreceive] pair. The former involves writing to disk, but the latter is even worse in that messes up depth-first order. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] symbol2list leading zero
On Thu, 2011-11-03 at 13:43 -0700, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: pd-list@iem.at Cc: Sent: Thursday, November 3, 2011 4:36 PM Subject: Re: [PD] symbol2list leading zero On Thu, 2011-11-03 at 08:33 -0700, Jonathan Wilkes wrote: From: Mathieu Bouchard ma...@artengine.ca If someone just wants to split lists instead of converting to floats and getting weird answers on pd-list, there's [gf/s2l], which does not do anything else than splitting (as it is like with any string-splitter outside of pd/max). Once split, is there a way to convert symbol-atom 19.95 to a float? Two work-arounds come to my mind: 1) Send the symbol to [textfile] save it as a file, read the file again and output the result. 2) Send it through a [netsend] / [netreceive] pair. The former involves writing to disk, but the latter is even worse in that messes up depth-first order. I've written Pd Vanilla hacks that do it without writing to disk Aha. and posted them on the list. Any pointers? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] expr alternative
On Wed, 2011-10-26 at 17:04 -0200, Ricardo Fabbri wrote: 1) if you want someone to change their licensing, at least be willing to offer them some cash. basically, you buy the new licensing. this part is not free! I would go as far as saying it's unpolite to ask to switch a license without offering money. What makes you think that it's more polite to offer money than offering cooking spaghetti with pesto sauce for all his/her friends or helping code something in another project? IMHO, one major advantage of being involved in open source software development is the freedom to contribute what I want, when I want, how much I want etc. and as long as there is no money involved it is easy to keep that freedom untouched. In a similar manner an author is free to change the licensing of their software whenever they want to whatever they want. Probably, this decision for a certain license was done carefully or rather in a light-headed manner. Either way, I'm not clear whether offering money is the (morally) right incentive to re-think that decision. One could even argue that it is corrupting the initial ideal of the original decision. When you say basically, you buy the new licensing this sounds to me very much like business lingo about commercial software and also like you were applying economic concepts of commercial software to open source software. To me it's not obvious that in order to get a different license you have to pay money for it. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] New versions of pd-l2ork now available on git
On Wed, 2011-10-26 at 09:42 -0400, Ivica Ico Bukvic wrote: All, Pd-L2ork is now available both as a tarball and via git: http://l2ork.music.vt.edu/main/?page_id=56 https://github.com/pd-l2ork/ Is this based on Pd 0.43 ? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fx chaining without glitch
On Thu, 2011-10-20 at 23:48 -0400, Hans-Christoph Steiner wrote: I think the way you'd do it to prevent glitches is to have them in subpatches, always attached, and then turn them on and off with a [*~] and a [switch~]. How are you gonna patch this without creating DSP loops? Roman On Oct 20, 2011, at 9:44 PM, patrick wrote: hi everyone, i would like to make a patch with multiple fx~ _but_ is it possible to chain the fx~ and change the order without a single glitch in the dsp. as an example: [adc~] | [reverb~] | [distortion~] | [dac~] now pressing a bang and automagically: [adc~] | [distortion~] | [reverb~] | [dac~] is it possible in pd? thanks, pat ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ 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
Re: [PD] fx chaining without glitch
On Fri, 2011-10-21 at 19:02 +0900, i go bananas wrote: here's a quick example with throw~ and catch~ This is actually a good example of how difficult / impossible it is to make it really glitch free with [send~ ] / [receive~ ], [throw~ ] and [catch~ ] respectively. During one block, you get weird results when switching. Check attached patch (your simpleRouting.pd with a grapher). Roman On Fri, Oct 21, 2011 at 4:57 PM, Roman Haefeli reduz...@gmail.com wrote: On Thu, 2011-10-20 at 23:48 -0400, Hans-Christoph Steiner wrote: I think the way you'd do it to prevent glitches is to have them in subpatches, always attached, and then turn them on and off with a [*~] and a [switch~]. How are you gonna patch this without creating DSP loops? Roman On Oct 20, 2011, at 9:44 PM, patrick wrote: hi everyone, i would like to make a patch with multiple fx~ _but_ is it possible to chain the fx~ and change the order without a single glitch in the dsp. as an example: [adc~] | [reverb~] | [distortion~] | [dac~] now pressing a bang and automagically: [adc~] | [distortion~] | [reverb~] | [dac~] is it possible in pd? thanks, pat ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list [W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity.-John Gilmore ___ 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 #N canvas 496 124 687 567 10; #X obj 16 151 throw~ \$0-fx1; #X obj -72 200 catch~ \$0-fx1; #X obj 62 202 catch~ \$0-fx2; #X obj -62 431 pack s \$0; #X msg -62 455 set \$2-\$1; #X msg -34 404 out; #X obj -76 502 throw~ \$0-fx2; #X msg -62 404 fx2; #X obj -60 352 r \$0-order; #X obj -60 376 sel 0 1; #X obj 94 442 pack s \$0; #X msg 94 466 set \$2-\$1; #X obj 96 363 r \$0-order; #X obj 96 387 sel 0 1; #X obj 62 509 throw~ \$0-out; #X msg 94 415 out; #X msg 122 415 fx1; #X obj 279 432 dac~; #X obj 263 144 s \$0-order; #X obj 261 107 vradio 15 1 1 2 empty empty empty 0 -8 0 10 -262144 -1 -1 0; #X text 278 107 fx1-fx2; #X text 279 123 fx2-fx1; #X obj 91 89 pack s \$0; #X msg 91 113 set \$2-\$1; #X obj 93 10 r \$0-order; #X obj 93 34 sel 0 1; #X msg 91 62 fx1; #X msg 119 62 fx2; #X obj 62 287 *~ 5; #X obj -74 286 +~ 2; #X obj 287 372 phasor~; #X obj 287 397 *~ 0.2; #X obj 287 347 mtof~; #X obj 288 304 catch~ \$0-out; #X obj -42 61 sig~ 10; #X obj 260 172 r \$0-order; #X obj 169 339 tabwrite~ glitchy?; #N canvas 0 0 450 300 (subpatch) 0; #X array glitchy? 1000 float 3; #A 0 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 52 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60 60
Re: [PD] Analyzing subharmonic frequencies accurately
Hi Sam If you're interested only in the lower frequencies anyway, you can drastically lower the sample rate in order to save some CPU cycles when doing the FFT. Roman On Mon, 2011-10-17 at 23:43 +0200, katja wrote: Hi, With fft~ you can go up to a framesize of 2^17, that is around 3 seconds when assuming 44.1KHz SR. The bin resolution is then ~0.37 Hz which may be just accurate enough for your purpose (spectral leakage will always make analysis less precise than the bin resolution suggests). Notice that the latency of your info will also be 3 seconds then. Katja On Mon, Oct 17, 2011 at 11:24 PM, Samuel Burt composer.samuel.b...@gmail.com wrote: A friend of mine asked me if I could make some kind of filter that could provide information about subharmonic frequencies. I wasn't quite sure what he meant, but I thought I'd try a few things to see what I could get. He mentioned he wanted the following bands 1-3 Hz, 4-6 Hz, 7-9 Hz, 11-14 Hz, and 15-18 Hz. The first thing I tried was a series of [lop~] and [hip~] filters in the ranges he was wanting. I stacked multiple [lop~]s and [hip~]s, to make really hard limits and then sent the output from each band to vu~ meters. This was unreliable. In fact, a 5 Hz sine wave seemed more likely to show up in the 10 Hz band. I also tried [bp~], [vcf~], and [svf~] with no luck. I then took a different approach, using [threshhold~] and [timer] to time the distance between zero crossings and output the result. This is very reliable for a sine wave, but I fear it wouldn't be that useful for real world signals. Have any of you ever tried to separate out subharmonic frequencies in Pd? Any experience with brain wave analysis in software? What's a better technique? Thanks, Sam in Baltimore ___ 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-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Reason for different keyboard behavior of vanilla numberbox and nbx (Number2)
On Mon, 2011-10-17 at 15:16 +0200, João Pais wrote: probably yes, but I don't know which might be as well. I think I've pointed that out some time ago, but it's still the same. Should we make a atom==nbox lobby? Actually, I can't think of a good reason not to be able to edit the numberbox with the keyboard anymore after hitting enter. Also setting it to '0' after the second enter keystroke does not seem very meaningful (and is quite annoying when playing 'live'). If it's not a feature, it's a bug, no? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Variable number of objects?
On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote: -- Forwarded message -- From: Ludwig Maes ludwig.m...@gmail.com Date: 28 September 2011 19:29 Subject: Re: [PD] Variable number of objects? To: Ingo i...@miamiwave.com I actually meant more in general, also for non-~ signals (i.e. also control rate .pd patches). I referred to polysynth such that people would see more easily what I meant. Are there really no such primitives? That seems like quite a restriction... How can that take 10 seconds?? I dont see what would cause such a huge overhead, i'd expect an increase in computations memory though (say from 10 voices to 11: 10% increase in cpu workload ram dedicated to these voices..., I fail to see what would necessitate a long initialization...) also, how is it done even with the long delays? As I understand it, the whole DSP is recompiled whenever it is changed. So, if you have a very large patch (and Ingo seems to be an expert in very large patches) and you create another voice, it's easily possible to eat up quite some time. Also, it's probably much slower the first time, if the voice abstraction is built of many other abstractions, which need to be read from disk. But I guess you are right about the increase in CPU workload _after_ the DSP graph has been recompiled: A switch from 10 two 11 instances is expected to show only an increase of 10% in CPU usage. It's been said, that often you can gain quite some time while turning off DSP during dynamic instantiation. But I guess, this makes only a difference when performing several instantiations at the same time. When DSP is on, each cycle would cause a complete DSP graph recompilation, whereas when DSP is off, it's only recompiled once (after turning it on again). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. Using [threshold~] or any other method to detect the reset of [phasor~] is not feasible, because of two reasons: * [threshold] (but also [snapshot~]) output the bang only at block bounaries, so the detection is not very precise * Whenever the the audio domain (a signal) causes an event in the message domain (that's what [threshold~] and [snapshot~] are for), the event is at least one block late. There is still one advantage of [phasor~] over [vline~]: The speed of the [phasor~] can be changed at signal rate, so one can create continuous pitch changes when playing the sample. That's not possible with [vline~]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
On Tue, 2011-09-20 at 09:43 +0200, Pierre Massat wrote: I m curious to know which object you would recommend instead of threshold~ (the delay way is obviously not feasible as soon as you need to change the speed of phasor~ during palyback). Yeah, [threshold~] seems feasible, but this approach suffers from a few issues. As I said before, the bang comes only on block boundaries and is at least one block late, so it's not very precise. Also, a [phasor~] probably never reaches exactly 1 (or 0) and it is less likely the higher the frequency is. So you would need values like 0.001 or 0.999 for the [threshold~] which again makes it a bit more imprecise. You can also use the [vline~] approach and change the speed in the middle of the playback, though it needs a bit of patching to accomplish that. You need a delay, that is triggered at the time of the speed change. The delay value can be used to calculate the current position of the play head. Then you can use that value as a start point for a new message to [vline~]. Roman 2011/9/20 Roman Haefeli reduz...@gmail.com On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. Using [threshold~] or any other method to detect the reset of [phasor~] is not feasible, because of two reasons: * [threshold] (but also [snapshot~]) output the bang only at block bounaries, so the detection is not very precise * Whenever the the audio domain (a signal) causes an event in the message domain (that's what [threshold~] and [snapshot~] are for), the event is at least one block late. There is still one advantage of [phasor~] over [vline~]: The speed of the [phasor~] can be changed at signal rate, so one can create continuous pitch changes when playing the sample. That's not possible with [vline~]. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
On Tue, 2011-09-20 at 10:06 +0200, Pierre Massat wrote: Yeah, a threshold~ set to 1 is never triggered (or very rarely). So there's no perfect answer to the question it seems... Hm... What do you expect the perfect answer to be? The [vline~] approach works pretty well. What do you miss? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] stop sample playback when phasor~ reset?
On Tue, 2011-09-20 at 11:59 -0700, Jonathan Wilkes wrote: - Original Message - From: Roman Haefeli reduz...@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: tim vets timv...@gmail.com; Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Tuesday, September 20, 2011 3:35 AM Subject: Re: [PD] stop sample playback when phasor~ reset? On Mon, 2011-09-19 at 14:00 -0700, Jonathan Wilkes wrote: From: tim vets timv...@gmail.com To: Pierre Massat pimas...@gmail.com; James Dunn ja...@4thharmonic.com; pd-list pd-list@iem.at Sent: Monday, September 19, 2011 4:08 PM Subject: Re: [PD] stop sample playback when phasor~ reset? When you use phasor~, you normally already know how long it will take for the sound to be finished playing (because you set its frequency to play it back at the proper speed) Store the information about the sound loaded (or recorded) and use that to stop the playback after one play duration. [del time] | [t b b] || [0( [0( [| [phasor] What's the benefit of this over a line~ based approach? [line~] is inferior to [phasor~] in that it only starts a ramp on block boundaries. Using [vline~] seems to me most flexible in terms of sample playback as it can start a ramp even in-between samples. That depends on how one uses [phasor~]. In the example above the initial ramp must start on a block boundary-- whatever is triggering [del time] must also send the relevent frequency to [phasor~] for playing the sound stored in the array. Those actions must happen with control objects, which means they will affect the signal objects at the beginning of the next block. However, for the ramp at the end of playback [phasor~] as used above can produce a ramp that begins/ends in the middle of a block ( [vline~] too), whereas [line~] cannot. Of course I'm just talking about situations implied by the example above, where the user is just triggering events sporadically using control objects. What do you mean by 'triggering events sporadically using control objects'? Aren't [delay] and [metro] also control objects? If those are generating the event, you have more precise timing than only block boundaries. We actually don't know what would be triggering the [del] in the above patch (or probably I missed it?). Either way, the above patch would convert the precise timing to only block boundaries timing because the frequency inlet of [phasor~] only evaluates control messages on block boundaries. Using [vline~ ], however, would actually use the precise timing of the event. Neither [line~] nor [vline~] will trigger a ramp in the middle of the current block, so if you're rule is IF sample playback THEN [vline~] [line~] there are probably times you're wasting cpu. Sorry, if I am missing your point, but how do you know that [vline~ ] wouldn't trigger a ramp in the middle of block in this case? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pd-extended.deb does (not) conflict with puredata.deb
Hi Hans I was going to install Pd-extended from here: http://autobuild.puredata.info/auto-build/2011-09-16/Pd-0.43.1-extended-20110916-ubuntu-natty-i386.deb on a Ubuntu 11.04 machine and I got this: Unpacking pd-extended (from Pd-0.43.1-extended-20110916-ubuntu-natty-i386.deb) ... dpkg: error processing Pd-0.43.1-extended-20110916-ubuntu-natty-i386.deb (--install): trying to overwrite '/usr/bin/pd', which is also in package puredata 0.42.6-2 dpkg-deb (subprocess): data: internal gzip write error: Broken pipe dpkg-deb (subprocess): failed in write on buffer copy for failed to write to pipe in copy: Broken pipe dpkg-deb: error: subprocess decompress returned error exit status 2 Errors were encountered while processing: Pd-0.43.1-extended-20110916-ubuntu-natty-i386.deb It seems, that 'pd-extended' is conflicting with 'puredata' without mentioning 'puredata' in the 'Conflicts:' section. I think either it should be mentioned there or - what I think would be the better solution, if possible at all - it should not try to overwrite /usr/bin/pd. I don't know the current state of Pd-extended-0.43, probably it's still very much work-in-progress. I thought I mention this anyway. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. The main difference to Romans approach is that it uses more fixed code to end up doing less when actually working. BTW I think Romans approach makes generally more sense for most cases since it is scalable and does not need any different code for any number of pins (up to 128 in the current version) which makes it much simpler to use. I have attached a patch that shows the difference between the two debyte methods. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). However, I can't tell you whether they are really faster in the real world. But you should be able to test it in your own setup with [realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million numbers in 0 logical time, stop [realtime]. Do the same with a [ 4]-[ 2] chain and compare the results. I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. You could also test the whole [pd digital message] subpatch with the above mentioned approach. Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Using one less tilde object somewhere in your patch would save some order of magnitudes of CPU power more of what you ever will be able to squeeze out of the [arduino]. Message processing is usually so cheap compared to signal processing, that most often it's hardly worth to focus on the message processing part, unless you deal with message rates of several thousands per second. This is certainly not always true, but in my own experience it most often is. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Fri, 2011-09-16 at 11:32 +0200, Roman Haefeli wrote: On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). It turns out that difference is not significant. On my box, processing 100 floats takes ~160ms ([mod],[div]) vs. ~150 ([],[]). Probably all the message parsing overhead is consuming more than the actual computation of the numbers. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] multiple arduinos
On Fri, 2011-09-16 at 14:20 +0200, olsen wrote: On 09/15/2011 04:55 PM, Ingo wrote: I just tried to open the help file on Windows XP and Natty and it crashes Pd on both platforms. hm that's a pity - anyone else similar experience? any hints how to reproduce this? which version of pd are you using? salutis It works for me on natty with Pd-0.43 vanilla . Which Pd version does crash? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Ingo Thanks for testing! On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote: Hi Roman, the new version works great! I'm glad to hear that. I made myself some testing objects around it. Maybe that could be useful if you guys ever get around fixing the help patch. I'll have a look. Thanks. I still think the version using individual debyte masks is far more efficient than this one. But as you pointed out this one is more scalable and might take care of boards coming in the future (I have just seen a mega clone with 70 or 72 digital inputs). Most people don't use incremental wheels timed to 1-2 ms - like I do - anyway. So efficiency shouldn't matter in 99.9% of the cases. I generally think it does matter. However, i don't have any concerns that the additional table look up causes an efficiency problem. Table lookups are usually very fast. It's probably a matter of taste, but I often find myself looking for an 'algorithmic' solution instead of copying very similar code several times around, even if the former is a bit less efficient than the latter. In this case, if using several [pd debytemask], it'd be nice to use an abstraction instead. However, if the original [mapping/debytemask] would be used, every (-1) instance would require a row of 8 [+ 8] objects, [+ 16], [+ 24], etc. respectively. So it would either end up with a lot of additional objects below all [debytemask] instances or multiple manually crafted [pd debytemask] with each containing slightly different code (as you implemented it) would be required. The additional [pd polychange] with table lookup is made of just a handful of objects. However, if it ever turns out, that in your setup the [arduino] abstraction eats a significant amount of CPU power (what I really doubt), I'll happily replace it by your version of [pd digital messages] if it helps. And yes, the goal should be to cover also 'edge' cases like your incremental wheel. The more use cases work well with Firmata / [arduino] the better. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Mittwoch, 14. September 2011 22:33 An: Roman Haefeli Cc: pd-list@iem.at Betreff: Re: [PD] pduino rewrite As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote: The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Yeah, exactly. I would like to be able to install [arduino] also on a plain Pd-vanilla setup with the least amount of additional effort. [comport] will always be needed, of course. Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 11:36 -0400, Hans-Christoph Steiner wrote: On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote: On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote: The reason why I didn't make an abstraction for the debyte is that I wanted to keep the number of files and dependencies as low as possible. I think this was the original idea of the rewrite, right? Yeah, exactly. I would like to be able to install [arduino] also on a plain Pd-vanilla setup with the least amount of additional effort. [comport] will always be needed, of course. Well, now you can and trivially install all but one of the dependencies for 'puredata' aka Pd vanilla using: apt-get install pd-cyclone pd-mapping pd-zexy Only moocow is missing. I'd bet it'll be much less work to package moocow then to rewrite and manage a fork of arduino.pd. I'm not sure about this, but I mostly agree with you. When packaging arduino as a pd-lib.deb, it would be trivial to add the dependencies. However, I find I found some rather ugly stuff inside [arduino] that I definitely wanted to get rid of, such as [prepend] from cyclone. On the long run, I don't see the point in having two different [arduino] classes to be maintained. If at some point, improvements of both can be merged to one class, I'm all for it. Even if it means re-adding some externals. But for stuff that is very trivial to do with vanilla classes, I don't see the point in using externals. And no, I really don't think that adds a lot of maintenance load to the class. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 13:29 -0400, Hans-Christoph Steiner wrote: On Thu, 2011-09-15 at 18:54 +0200, Ingo wrote: Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. Makes sense, I think having it as a Pd abstraction is good too, I did write it that way rather than in C :) I was just saying that C would be more efficient. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. But then you need a row of [+ 8] ([+ 16], [+ 24]) for each instance of debytemask. So, it's still tedious work, whether you're using an abstraction or copies of the subpatch. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction anymore in the git version of [arduino]. I replaced it by a subpatch. Roman On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote: There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed is bug for over two years! #N canvas 490 1631 331 170 10; #N canvas 571 1511 538 392 digital 0; #X obj 58 3 inlet; #X obj 58 286 outlet; #X msg 58 113 0 \$1; #X msg 96 113 1 \$1; #X msg 134 113 2 \$1; #X msg 172 113 3 \$1; #X msg 210 113 4 \$1; #X msg 248 113 5 \$1; #X msg 286 113 6 \$1; #X msg 328 113 7 \$1; #X obj 58 208 +; #X obj 394 106 15; #X msg 58 261 digital \$1 \$2; #X obj 394 127 * 8; #X obj 58 230 pack float float; #X obj 58 163 unpack float float; #N canvas 0 69 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X obj 32 186 change; #X obj 82 187 change; #X obj 132 187 change; #X obj 182 187 change; #X obj 232 188 change; #X obj 282 189 change; #X obj 332 189 change; #X obj 382 189 change; #X connect 0 0 25 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 26 0; #X connect 19 0 27 0; #X connect 20 0 28 0; #X connect 21 0 29 0; #X connect 22 0 30 0; #X connect 23 0 31 0; #X connect 24 0 32 0; #X connect 25 0 8 0; #X connect 26 0 9
Re: [PD] pduino rewrite
On Wed, 2011-09-14 at 11:48 +0200, Ingo wrote: Hi Roman, thanks for taking the time looking at the code. Unfortunately your version will be sending even many more wrong numbers. I have put some list messages into your patch. Keep clicking onto them randomly and you will see that the headers change between 6, 7, 14 and 15. Sometimes they are correct - sometimes not. The problem is due to the change object inside the debyte object. Leaving it out would always send all 8 bits for the group of pins. Leaving it in will keep holding old values. Gotcha. I removed the [change] objects from the [pd debytemask] subpatch. And I also agree, that it would be ugly, if digital pins fire without changing their state. I cannot see any way other than using individual debyte objects for each group unless you would come up with something completely different like storing everything into an array and sending from there (after checking what has changed) which would be much more complicated. Actually, I found the table based approach not that complicated and I think it is more scalable (it covers all possible 16 groups). I added a [pd polychange] subpatch that does exactly what you describe. I hopefully tested it more thoroughly this time. See attached patch. Cheers Roman #N canvas 0 53 450 300 10; #N canvas 179 119 538 392 digital 0; #X obj 42 17 inlet; #X obj 42 334 outlet; #X msg 42 120 0 \$1; #X msg 80 120 1 \$1; #X msg 118 120 2 \$1; #X msg 156 120 3 \$1; #X msg 194 120 4 \$1; #X msg 232 120 5 \$1; #X msg 270 120 6 \$1; #X msg 312 120 7 \$1; #X obj 42 215 +; #X obj 378 113 15; #X msg 42 310 digital \$1 \$2; #X obj 378 134 * 8; #X obj 42 237 pack float float; #X obj 42 170 unpack float float; #N canvas 289 142 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X connect 0 0 8 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 9 0; #X connect 19 0 10 0; #X connect 20 0 11 0; #X connect 21 0 12 0; #X connect 22 0 13 0; #X connect 23 0 14 0; #X connect 24 0 15 0; #X restore 42 85 pd debytemask; #X obj 42 38 t a a; #X msg 69 60 \$1; #X msg 42 60 \$2; #N canvas 315 128 443 301 polychange 0; #X obj 23 20 inlet; #X obj 23 242 outlet; #X obj 236 12 table \$0.digital.in.cache 128; #X obj 23 87 tabread \$0.digital.in.cache; #X obj 23 64 unpack f f; #X obj 23 109 !=; #X obj 23 131 sel 1; #X obj 23 42 t a a; #X obj 23 153 list append; #X obj 83 242 tabwrite \$0.digital.in.cache; #X obj 23 175 t a a a; #X msg 248 215 \$1; #X msg 83 213 \$2; #X connect 0 0 7 0; #X connect 3 0 5 0; #X connect 4 0 3 0; #X connect 4 1 5 1; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 7 0 4 0; #X connect 7 1 8 1; #X connect 8 0 10 0; #X connect 10 0 1 0; #X connect 10 1 12 0; #X connect 10 2 11 0; #X connect 11 0 9 1; #X connect 12 0 9 0; #X restore 42 273 pd polychange; #X connect 0 0 17 0; #X connect 2 0 15 0; #X connect 3 0 15 0; #X connect 4 0 15 0; #X connect 5 0 15 0; #X connect 6 0 15 0; #X connect 7 0 15 0; #X connect 8 0 15 0; #X connect 9 0 15 0; #X connect 10 0 14 0; #X connect 11 0 13 0; #X connect 12 0 1 0; #X connect 13 0 10 1; #X connect 14 0 20 0; #X connect 15 0 10 0; #X connect 15 1 14 1; #X connect 16 0 2 0; #X connect 16 1 3 0; #X connect 16 2 4 0; #X connect 16 3 5 0; #X connect 16 4 6 0; #X connect 16 5 7 0; #X connect 16 6 8 0; #X connect 16 7 9 0; #X connect 17 0 19 0; #X connect 17 1 18 0; #X connect 18 0 11 0; #X connect 19 0 16 0; #X connect 20 0 12 0; #X restore 7 13 pd digital messages roman; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Can GEM select a color from an image?
On Sat, 2011-09-10 at 22:33 -0400, Mathieu Bouchard wrote: On Sun, 11 Sep 2011, Olivier B wrote: I think [pix_mean_color] is what you need. This only finds the average colour, which is usually not the same as the most prevalent colour, even though it is the best estimator. The best estimator means that it's your best guess when someone asks you to predict pixels picked randomly in the image. It leads to least square error : (predicated - random)² is as low as it can be, on the long term. In statistics, we learn about Average, Median and Mode, usually all 3 at once, as 3 basic approaches, three kinds of «middles» of the data. What Sebastian is looking for is more like Mode, which looks like the easiest of the 3, but is actually the hardest of the 3, especially when doing in multidimension spaces (such as red,green,blue) and on continuous scales (256 values per dimension is continuous enough for what I'm talking about). There are several gotchas about peaks in statistical distributions. I wonder how one should go about this: Let's assume an image consisting of the major parts of pixels that are at most -/+3 values (from 256) apart from each other in every plane (R, G, and B). So this pixels would be spread across 7x7x7 = 343 different colors, but would look still very similar to each other. Now, the rest (minor part) of the image consists of all the exact same color value, which is much different from the colors in the major part. Am I right in thinking, that the Mode would detect the minor part (with all the exact same color values) as the most prevalent color, while the human eye most likely would see a mix of the previously described color variation as the most prevalent color? How would an algorithm work, that would take into account that all the pixels from the major part are very similar and thus would detect a mix of those as the most prevalent color? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] OSC Confusion
On Wed, 2011-09-07 at 21:00 -0700, Jim Aikin wrote: This leads me to a concatenation of questions. (1) Does the fact that OSCroute, sendOSC, and dumpOSC are deprecated mean that they actually don't work, or do they still work? They probably still work, but are not maintained actively anymore and are known to be buggy. The mrpeach OSC object classes are more low level, but also more flexible, less buggy and actively maintained (2) Where can I get a version of Pd-extended that includes the new, preferred OSC objects? They most likely are included in your version already. Pd-extended does _not_ load _all_ libraries by default, which is IMHO a good thing. You can easily load a library from your patch by putting a [import mrpeach] in it. (3) If there is no such version, how exactly would I go about incorporating them in 0.42.5? Not necessary. (4) What sort of patching will I need to do in order to connect the mrpeach objects with the [udp] objects after I've installed them, and where is this patching documented? Check the helpfiles for [packOSC] and [unpackOSC], they show how to hook up the OSC object classes with the net (udp|tcp) object classes. Sorry to be a pest about this. Right at the moment I'm trying to document the usage of OSC to let Pd communicate with Csound. Andres Cabrera's very nice tutorial video (on YouTube) uses the old Pd objects. I'd like to use the new objects in the tutorial I'm writing, but I can hardly do so when I don't understand where the objects are or how to install them. Cool. I strongly recommend to use the mrpeach OSC classes. BTW: you find a lot of info in the mailing list archives about this topic. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file
On Sun, 2011-09-04 at 14:23 -0400, Hans-Christoph Steiner wrote: On Aug 31, 2011, at 2:33 AM, Chris McCormick wrote: On Tue, Aug 30, 2011 at 11:19:46PM -0700, Miller Puckette wrote: I am in favour of having that functionality as part of [list] and those names look good to me. For the functionality you describe maybe something like [list ascii2symbol] and [list symbol2ascii]? Those would also be pretty useful! I am currently making a [split] abstraction based on Jamie's work. I will send it through when I am done - or you can just look at symbol2list's source which IOhannes has re-licensed in a message to this list for use in Pd: hmm... another possibility, as in lisp: list explode and list implode ? Also good! My idea is that, once this is in Pd vanilla, the 2/3 - 2 3 type of split is easy enough to program in an abstraction, but it's presently not possible at all; meanwhile, the funtionality I'm describing is pretty canonical and hard to split up into finer components in any way I can see. Ah, ok, so you could do: bat/cat/rat - 98 97 116 47 99 97 116 47 114 97 116 and then you would run through the number list finding 47 (/) and re-building the separate symbols using the reverse operation. I guess this would be cool because it would also allow you to store proper strings with all kinds of characters in regular Pd arrays, which might be fun. Hmmm, also many other things! easy enough to program in an abstraction, but it's presently not possible at all; After looking at Jonathan's ratio splitting abstraction I think this might actually be possible with [makefilename] madness, but it's much uglier than what you propose: http://lists.puredata.info/pipermail/pd-list/2011-08/090196.html Definitely check out Bryan Jurish's moocow with its bytes2any and any2bytes. They work quite nicely for converting between messages and lists of byte floats and are easy to use. I made a vanilla abstraction similar to [byte2any] based on the aforementioned [makefilename] madness. Just for the sake of this discussion. Check the attachment. Roman byte2string.tar.gz Description: application/compressed-tar ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] how to change bp~ frequency at sample rate?
On Fri, 2011-09-02 at 19:57 +0200, Menno van der Woude wrote: Hi all, working on patches that will be controlled by video analysis (through OSC messages), I am wondering how to change the frequency (second inlet) for [bp~] in realtime. The problem is: connecting a [line] object or number object to this inlet will result in clicks and pops when the line is moving very fast or changes are rapid. Is there a way to change the frequency for [bp~] at sample rate? Or should I use another object to achieve this kind of realtime cutoff/resonance changes? According to its helpfile, [vcf~ ] is the same as [bp~ ], but with a voltage controlled aka signal rate inlet for frequency. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] making puredata headphone-safe
On Mon, 2011-08-29 at 12:19 -0400, Martin Peach wrote: On 2011-08-29 11:52, Hans-Christoph Steiner wrote: On Aug 23, 2011, at 3:43 PM, Martin wrote: On 23/08/11 03:29 PM, Stephen Lavelle wrote: I've managed to hurt my ears twice over the past two days when using PD w/ headphones. Even at lowest system volumes, it seems that Terrible Things can happen. Are there any precautions that I can take to make it feel less like I'm taking my life into my hands when I have to use headphones? Try making a [noise~] connected directly to a [dac~] and set the headphone volume so you can live with that. Nothing will ever be louder than that. Hmm, I don't think that's actually true in all cases. On a MacBook Pro running Mac OS X, I've had the volume set to one above mute, but had massive feedback from LPC patches that were very very loud. [noise~] would be very comfortable at that volume setting. I think some platforms do the output mixing in the digital domain, so my min volume would be [*~ 0.01], so that this would still make a very loud sound: [noise~] | [*~ 99] | [*~ 0.01] (i.e. the Apple output mixing) | In this particular case, the sound output actually gets shutdown entirely, so you have to reboot to get sound output again. That make no sense. How can you have two sounds at the same level going into a mixer that come out at different levels? Or do you mean that a squealing sound is perceived to be louder than white noise? Maybe you could demonstrate with a patch? I always had the feeling, that on OS X on MacBooks (Pro) the sound coming from the speakers is heavily processed. Audio sounds a lot 'punchier' than for example the same audio played on the same machine from Linux. I haven't had a chance to play around with it, since I don't own a MacBook, but from what Hans says, to me it sounds as the application output is not clipped to -1/1 before going to the (CoreAudio internal?) dynamics stage, but processed and limited first and only then sent to the speakers. This would also explain, why the setup Hans explained above would completely shutdown the sound output. Probably, if you wait long enough, sound would come back again, assuming that it's the limiter's release time, that becomes very long due to the very high level coming in... just my 2¢ Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] Relaunch of the RadioSolarKompass
Hi all Today starts the 'CONNECT' exhibition [1] where the RadioSolarKompass [2] by Anja Kaufmann and me is shown. It's actually a project from 2005, but was redone from scratch for this exhibition. The RadioSolarKompass is a web radio that follows the sun around the world. Radio stations from all over the world are broadcasted, depending on their location. At any one time radios from those locations are played where the sun currently is rising. At the core, the RadioSolarKompass is driven by a Pd patch. [1 en] http://www.shedhalle.ch/en/wed-1307-opening-connect-art-between-media-and-reality [1 de] http://www.shedhalle.ch/de/ausstellungen/connect-kunst-zwischen-medien-und-wirklichkeit [2] http://www.radiosolarkompass.org/ Direct Stream URL: http://www.radiosolarkompass.org:8010/rsk.mp3 Enjoy! Roman ___ 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] click sound when saving
Hi Jamie
Am I right in thinking, that you get this click even while all your
audio modules are silent? At least, that is what the click.wav file
suggests.
I assume there are two things involved that cause the clicking:
* When doing a lot within 0 logical time, you'll get audio drop outs,
because the computer is not fast enough doing the requested task in the
defined time frame (which is: your buffer size). This often happens
while loading or saving presets.
* It seems one or more of your audio modules contain a bit of DC
('direct current' or constant) in their signal. Make sure to avoid that
whenever possible, since DC decreases the dynamic range available and
makes your amps and speakers consume a lot of energy without any
benefit.
Now, if you really have a certain amount of DC going to your [dac~] and
there is a drop-out (see reasons above), this will be audible, because
during the drop-out the signal switches to 0 and after the drop-out back
to the DC level. I think that is the reason for your clicks.
For a quick test, you could put a [hip~ 5] right before the [dac~] and
check if the clicking still occurs. A high-pass filter will remove any
DC components from the signal, but the better solution would be not to
generate a DC in the first place.
Roman
On Tue, 2011-06-28 at 04:00 -0700, Jaime Oliver wrote:
Hi all,
I have two patches.
One is my stable version and the other is the development one.
They are similar, but I've made many changes.
However, this development version now makes this click sound (attached
or in www.jaimeoliver.pe/misc/click.zip)
The click happens when editing, saving or sending control messages to
the audio modules. Deleting the audio modules eliminates the problem,
but I need those.
Anyone has any idea where to look for possible problems?
best,
J
___
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
Re: [PD] Piezo, trigger, Arduino
On Wed, 2011-06-22 at 15:06 +0200, Pierre Massat wrote: Thank you all for your advice. @Roman : what type of op-amp do you use? I guess, it was Martin Peach who suggested using an op-amp. However, I think many common ones will do. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Piezo, trigger, Arduino
Hi Pierre Actually, I wouldn't connect the piezos to an arduino, but to a sound card, because the piezos will likely give very very short spikes and the sampling rate of the analogIns of the arduino is quite low (don't know the exact value) compared to the sampling rate of a common sound card. Also, you have more control in Pd to build a trigger detection filter then on the arduino. Also you would likely get much lower latency with a good audio setup than with the atmega-ftdi-usb-comport path. Also when using the soundcard, the latency is constant, while you would have glitches with the arduino. I'd be glad to hear other opinions, though, since my thoughts are purely theoretical. I haven't implemented a piezo-based trigger, neither with sound card nor arduino. Roman On Fri, 2011-06-17 at 14:27 +0200, Pierre Massat wrote: Dear List, This is yet another question about Arduino. Sorry about that. I want to use piezos to trigger samples using my arduino board. I want the trigger to be sensitive, and a quick google search seems to show that piezo is the way to go. Does anybody have any experience with piezo triggers (what type of piezo, isolating each piezo, etc.)? I will hit the piezos with my bare fingers (no drumsticks or anything like that), but i guess it doesn't really matter since i can control the threshold within Pd. This last sentence is just to make sure that everyone knows i'm talking about piezos in case there wasn't enough occurences of the word in my message. Cheers! Pierre ___ 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
Re: [PD] Launching puredata -nogui from a terminal
On Fri, 2011-06-17 at 16:39 +0200, Matteo Sisti Sette wrote: Hi, If I launch Pd from a terminal (without ), when the terminal is closed Pd dies, which is fine for me. However, if from the terminal I launch Pd with the -nogui option, then it survives and keeps running even if the terminal is closed. Is there a way to launch Pd from a script with -nogui in such a way that when the terminal in which it was launched is closed, the Pd process is also killed? Hm.. don't know why it shows this behaviour with -nogui. Perhaps the pd process is a child process of the pd-gui process, and probably pd-gui immediately stops running after launch when -nogui is set, thus pd is not a child process of the terminal and won't shutdown when the terminal is killed? just some thoughts Anyway, you still could send the 'pd -nogui' process to the background and then later kill it by its process ID: $ pd -nogui $ pdpid=$? and later: $ kill $pdpid Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
On Mon, 2011-06-13 at 13:57 -0400, Hans-Christoph Steiner wrote: On Jun 13, 2011, at 1:48 PM, Ingo wrote: With the latest version, the only way I've found that actually works to enable analog input pins are the so-called old messages analogIns npin 1/0 /listinfo/pd-list I was mentioning that before. I had the same problem. There is another problem with the digital ins 1 and 2. I got myself a workaround. Unfortunately I don't remember anymore what it was exactly. It happened when you went from pin 1 or 2 to another one and back. The first value came out as a 0 instead of the correct version. I think it had to do with the fact that pins 1-8 should form a 8-bit number but 1+2 are part of another 8-bit number or something like that. It happens somewhere in the part of the mapping. Ingo I'm totally swamped these days, getting ready for a baby that's coming soon. Please submit bug reports, patches, help file updates, and I'll get to it when I can. @Ingo and Matteo I'm also quite interested in having the [arduino] working properly. I didn't find any bugs recently, though. However, if you provide a step-by-step guide about how to reproduce a problem, I (and probably Olsen also) might be able to help, as I know the code inside a bit, although I'm not the author (as long as the problem exists on the Pd side and not on the Firmata side). Regarding the help and test files, we just improve what needs improvement. I hear that this is OK with Hans. @Hans I wish you guys good luck and a happy baby! Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] loading patches very slow in linux
On Mon, 2011-05-16 at 17:56 +0200, Matteo Sisti Sette wrote: On 05/16/2011 05:09 PM, Claude Heiland-Allen wrote: Another thing to possibly check is whether dsp is on or off when you load patches, perhaps? Thank you, I already checked that (it's off), and the same happens with a big patch that has no dsp and which I run with -noaudio... -noaudio does not mean 'do not do any DSP', it only means 'don't occupy any soundcard'. It's still possible to start DSP when -noaudio is used. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] msg to abstractions
On Thu, 2011-05-05 at 11:31 +0200, Jeppi Jeppi wrote:
Hi again,
just another question regarding the pd-msg system. Say I have two
parametrized abstractions [boo 1] and [boo 2] loaded in my patch. When
I send a message to them to dynamically create some objects inside, I
send it as
[obj 20 30 metro 100(---[s pd-boo.pd]
which, of course, goes to both instances.
Would it be a way to send the message only to a single instance, maybe
taking into account the creation parameters?
Adding prefix to the abstraction names is not elegant, as that would
require previously creating n abstractions, named [1_boo] , [2_boo]
and so on...clumsy
You could use the object [namecanvas] to name each of your instances of
your abstraction differently. Exactly this setup is the reason why me
(and many others) think that this object class shouldn't be deprecated
at all, as stated in the help-file.
Just put a [namecanvas $1_boo] into your abstraction. Then you can
address each instance separately ('1_boo', '2_boo', etc.) when sending
it pd-msgs.
Roman
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] [wiimote] accelerometer data missing?
Hi Jason A few people from this list worked on getting [wiimote] into Debian. Under unstable / sid it is already available as the package 'pd-wiimote'. I'd be glad, if you could try this one and report if it is working with your device. Note: It depends on the meta-package 'pd' thus it will probably install 'puredata', although you have a Pd version already installed in /usr/local/. However, this shouldn't hurt at all. I just want to let you know, and also to take care to set proper paths for your locally installed Pd, since the 'pd-wiimote' will install into /usr/lib/pd/extra. Roman On Tue, 2011-04-12 at 00:02 -0700, Jason Plumb wrote: Hi list. I've got [wiimote] compiled and almost working with 0.43 vanilla...except that the accelerometer data doesn't seem to be working. I've got (what I think is a) latest generation black wiimote with built-in Motion Plus, and my testing was without the nunchuck or anything attached. I can discover the device and the help patch shows all the button presses and I can toggle the LEDs and vibrator using the help patch, but even after clicking the toggle the accelerator data is just absent. I believe that an extra blank line shows up in the Pd console when I send the accel activation message, but aside from that there's just nothing. I read the blurb in the [wiimote] readme about the problems with older versions of libcwiid, but I've got 0.6.00+svn201-2+b2 from debian sid, which I believe is pretty damn close to the latest... Has anybody experienced this? Any suggestions other than compiling libcwiid myself and trying out the motionplus_sensitivity patch? Thanks! -jason http://noisybox.net ___ 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
Re: [PD] moses Object in Pd -- and in MAX ?
Sorry for not being of any direct help, but wouldn't this question be more appropriate for a Max user list or forum, assuming that most people here know Pd much better than Max? Cheers Roman On Thu, 2011-02-17 at 13:15 +0100, hghoyer wrote: Hi, i´m Benchmarking Pure Data Max... So, in PD there ist the [moses] object... lokk at the picture... Is there a similar Objekt in MAX? Best regards, hgh ___ 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
Re: [PD] iemmatrix mtx_.*
On Mon, 2011-02-14 at 10:12 +0100, IOhannes m zmoelnig wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-02-11 22:12, mami music wrote: Sorry for 100th posting i found a way (maby its also the 100th time someone describes it): I copied [iemmatrix 0.2] as the first object in the patch. (i erased all the patch, created the [iemmatrix 0.2] object and then pasted it back). Even tough the [iemmatrix 0.2] object seems not to be created, the [mtx_.*] is created and it works Did you consider my other mail? Have you tried putting this to your patch: [import hexloader iemmatrix] Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] iemmatrix mtx_.*
On Fri, 2011-02-11 at 22:02 +0100, IOhannes zmölnig wrote: On 02/11/2011 09:56 PM, mami music wrote: Hi Im having trouble using this object [mtx_.*] in a patch. It never loads when i start the patch. I have to go to help/browser/examples/iemmatrix/mtx_mul and open that example. Just after I open that example I can rewrite the object and i get it to be created properly. How can this be solved and be able to load the patch from the start without repeating this exercise of opening the examples, etc? it has been discussed a 100 times on this list. you either have to load iemmatrix as a single library (that is how it is intended; unfortunately PdExtended doesn't ship iemmatrix as a library, but only as single objects, that have a lot of trouble with special characters like *), or you have to load mtx_mul beforehand. luckily, you don't have to open the help-patch, but you can simply create a [mtx_mul] object. Alternatively, you could put [import hexloader iemmatrix] in your patch and then [mtx_*] and the like will be loaded without troubles. Unfortunately, hexloader which is supposed to fix this kind of loading problems is _not_ loaded by default in Pd-extended. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Maybe I'm pushing dynamic object creation too far
On Wed, 2011-02-02 at 23:25 +, Ed Kelly wrote: On 2011-02-02 01:00, Ed Kelly wrote: I get dropouts, regardless of the jack buffer size/buffers number. Is this because the dynamic creation of a new object interrupts the pd audio stream? If so, can this be alleviated - 1. is it a GUI problem (and will pd 0.43 fix it) and 2. if so, can pd -nogui sort it out? the problem most likely comes from the DSP graph being continuously rebuilt. the only things you can do for now is: - - try to reduce rebuilding of the DSP graph as much as possible. needeless to say that you shouldn't dynamically create objects that are not needed. more interesting is that e.g. creating 3 objects while audio is running, will re-caculate the DSP graph 3 times. even if this happens in 0 logical time. so i you know you are going to schedule several dynamically created objects at once, turn audio off before and turn it on again after you do the actual creation. Dammit! Only one at a time, but they are tables of perhaps 30 points. Then I copy data from the input buffer into the table. In your situation I'd try to do everything that doesn't necessarily need to happen in 0 logical time to extend to 0 logical time. Unless you really need the new tables immediately after the buffer was filled, I'd suggest to copy them over 'slowly'. One approach once mentioned by Miller Puckette is to do array copying by doing it in the audio domain within an upsampled sub-patch. This would make DSP drop-outs during array copying much less likely. It has to be running with the audio, since the audio is being re-mixed in real time. Wrong. Dynamic creation happens in 0 logical time. Now let's consider a case where you dynamically create several objects in one go. After every single object the DSP graph is recompiled. The real time this process takes is quite high. Now if you'd first turn off DSP, create all necessary objects dynamically and then turn DSP on again, the DSP graph is recompiled once and the real time this takes is much shorter. If you're lucky, it will be so short (shorter than your current audio buffer setting), that you don't even notice a drop out. Just to make myself more clear: It's perfectly possible to turn DSP off and on again in 0 logical time without noticing it at all, even when there is some audio processing going on. Everything works fine if I'm using the onboard sound - e.g. OSS, but the problems only happen when I switch to jack. Of course the onboard sound would be OK if I was using only output, but the whole point is to live-sample the input. The mic input on my laptop is really crappy. - - try to get the DSP graph building into a separate thread. well, this involves pd~ or the like Dammit again - I'm using the second core of the machine for the live score, dynamic object creation in GEM - but I see the new version of Inscore supports PD, so all my work over the last 6 months has been for nothing. I wouldn't be too sure about that. Try to figure out what needs to really happen in 0 logical time, since most often the problems of audio drop outs is that Pd is requested too much to compute in 0 time. Try to distribute as much as possible over time, so that as many things as possible happen continuously and as little things as possible need to be calculated instantly. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Re: wiimote crashes with moderate cpu load and/or heavy USB transfer
On Thu, 2011-01-27 at 11:00 -0500, Ivica Ico Bukvic wrote: It should be included with the actual external. I'm afraid the archive from: http://l2ork.music.vt.edu/data/pd/disis_wiimote-0.6.5.tar.gz doesn't contain a help patch. Roman Roman Haefeli reduz...@gmail.com wrote: On Wed, 2011-01-26 at 20:21 -0500, Ivica Ico Bukvic wrote: Forgot to copy pd-list... Original Message Subject: Re: [PD] wiimote crashes with moderate cpu load and/or heavy USB transfer From: Ivica Ico Bukvic i...@vt.edu To: John Harrison johnharrison...@gmail.com CC: Try disis_wiimote from the L2ork software page which uses threaded implementation and is dsp-safe even when sending cues back to wiimote (which otherwise cause consistent xruns). We use it regularly even at heavy cpu loads and it is rock solid (Linux only). Cheers! Is there also help-file / help-patch available for [disis_wiimote]? Or is it supposed to work the same as the [wiimote] it is based on (can't test right now). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ubuntu/ubuntustudio 10.10 pd pd-extended?
Hi On Fri, 2011-01-28 at 08:37 +, J. Simon van der Walt wrote: I've installed ubuntu 10.10 on my netbook, and on top of that the audio packages from ubuntustudio. This is working well. For Pd, however, I *think* what I have is a vanilla installation, rather than extended, which I would like. In Synapctic Package Manager I can see I have puredata 0.42.6-1build1 plus a version of gem, but I can't seem to see anything in Synaptic which looks like Pd extended. Do I have to add a software source or something? AFAIK, there is no repository delivering Pd-extended. Alternatively, on http://puredata.info/downloads I see a link to: http://downloads.sourceforge.net/pure-data/Pd-0.42.5-extended-ubuntu-maverick-i386.deb Should I download that instead? Yes. Should I remove the existing installation? You can, if you want, but it's not mandatory. You most certainly have Pd vanilla installed now and both, Pd-extended and Pd, can happily live side-by-side nowadays. (Please excuse the perhaps slightly naive 'now-click-here' tone of this question: it's deliberate. So far I've managed to get this machine installed and running the way I want it without using the terminal once, just coming at it like I would on the mac or pc. I'm trying to keep going on ubuntu sticking to this policy, partly just to prove whether or not it can be done...) Good luck! (I'm confident it's possible, though) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] standard encoding of pd files in each system?
On Wed, 2011-01-26 at 22:54 +0100, João Pais wrote: For converting, I like moocow/any2bytes and moocow/bytes2any. I think I had a look at it as well. do you have any comparative reason for that one instead of the other? or it was just the first one to get to you? One important thing to know is that [mrpeach/str] only works with Pd-extended, but not with Pd-vanilla as it requires some modifications to m_pd.h. Btw @Martin: Do you think it's time again to to try to get the blob support into Pd-vanilla? I think that [str] would be utterly useful also in vanilla and it didn't seem to have caused any problem in Pd-extended, did it? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Re: wiimote crashes with moderate cpu load and/or heavy USB transfer
On Wed, 2011-01-26 at 20:21 -0500, Ivica Ico Bukvic wrote: Forgot to copy pd-list... Original Message Subject: Re: [PD] wiimote crashes with moderate cpu load and/or heavy USB transfer From: Ivica Ico Bukvic i...@vt.edu To: John Harrison johnharrison...@gmail.com CC: Try disis_wiimote from the L2ork software page which uses threaded implementation and is dsp-safe even when sending cues back to wiimote (which otherwise cause consistent xruns). We use it regularly even at heavy cpu loads and it is rock solid (Linux only). Cheers! Is there also help-file / help-patch available for [disis_wiimote]? Or is it supposed to work the same as the [wiimote] it is based on (can't test right now). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] zero crossing
On Mon, 2011-01-17 at 02:01 +0100, Dietrich Pank wrote: Thank you Roman, I do think it is possible to get sample correct bangs from analyzed audio: http://lists.puredata.info/pipermail/pd-list/2010-12/085681.html Ok! After reading this tip again I understood it something better. But..well, one block later may be accourate theoretically but not real(time). True. But this is a logical problem that also an external wouldn't be able to solve. The results of some analysis of data cannot be delivered before the data was delivered. With a block size of 1 this latency could be improved, but it would be still one sample late, so still not real-time in that sense. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] zero crossing
On Mon, 2011-01-17 at 09:39 +0100, Pierre Massat wrote: Seems to me like nothing is ever realtime in DSP anyway... I guess that is what IOhannes meant when he suggested to re-think the definition of 'real-time'. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] zero crossing
On Sun, 2011-01-16 at 06:15 -0800, ronni montoya wrote: Hi, how can i calculate zero crossing in pd? is there any librery or something? http://www.google.com/#q=site%3Alists.puredata.info+%22zero+crossing%22 Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] zero crossing
On Sun, 2011-01-16 at 22:01 +0100, Dietrich Pank wrote: 2011/1/16 Roman Haefeli reduz...@gmail.com On Sun, 2011-01-16 at 06:15 -0800, ronni montoya wrote: Hi, how can i calculate zero crossing in pd? is there any librery or something? http://www.google.com/#q=site%3Alists.puredata.info+%22zero +crossing%22 This link feels a bit like reed the FAQ (I was also asking the same in principle some weeks ago) ok, but: There is no answer. AFAIK it's impossible to get sample correct bangs from (anaylysed) audio. I didn't mean to say 'RTFM' or similar, but it's an ever arising topic and probably the answer is already covered. I do think it is possible to get sample correct bangs from analyzed audio: http://lists.puredata.info/pipermail/pd-list/2010-12/085681.html Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] netpd-now
On Sat, 2011-01-15 at 02:40 +0100, Max wrote: log in! Sorry, that was too late (or too early) for me. Did anyone join you? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] change in compression detection
On Wed, 2011-01-12 at 19:23 -0500, Mathieu Bouchard wrote: On Wed, 12 Jan 2011, Roman Haefeli wrote: On Wed, 2011-01-12 at 13:35 -0500, Mathieu Bouchard wrote: If you pick compressor settings that cause their cutoff wavelengths to be longer enough than the sounds you are compressing, they will cause no (or little) distorsion in the perceived frequencies, and thus it will not sound like a compressor. Di you mean: [...] thus it will not sound like a wave shaper? ouch, yes. But constant-amplitude sound can also be music, can't it ? Sure, though I don't know any, I guess. Musical xmas cards, cellphone ring tones, pc speaker, etc. There are lots of examples. True, in those examples the sound generation is often based on square waves with constant amplitude. If we want to be very nit-picking, those still don't qualify for constant amplitude sound sources, since one usually doesn't listen to those sounds with headphones plugged directly to the christmas card. Even if at an electrical level the amplitude is constant, it's very likely that it is not constant anymore when you record the sound with a microphone. This is due to resonances and distortions introduced by the physical properties of the speaker (piezo) and the paper of the card. Also it wouldn't be interesting to detect compression in it. And then what ?... If you talk about compression of dynamics in general, you're talking about all sounds, and not just those that are interesting. If we consider all kinds of sounds, there still might be a portion of it, that is not so interesting for compression detection. What's wrong with that with stating that? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] change in compression detection
On Wed, 2011-01-12 at 13:35 -0500, Mathieu Bouchard wrote: On Tue, 11 Jan 2011, Roman Haefeli wrote: I hope I'm not confusing dynamic range compression with wave shaping. Actually, depending on the compressor settings (short attack times, etc.) a dynamic compressor indeed acts a bit as a wave shaper. It can also act exactly like a waveshaper, if you give it the most extreme settings. Similarly an echo effect and a comb filter are the same thing, but when people talk about an echo effect, they usually don't mean an echo effect configured to act as what is usually meant when people say a comb filter. And vice-versa. If you pick compressor settings that cause their cutoff wavelengths to be longer enough than the sounds you are compressing, they will cause no (or little) distorsion in the perceived frequencies, and thus it will not sound like a compressor. Di you mean: [...] thus it will not sound like a wave shaper? Instead of constant amplitude signals think of signal with ever changing amplitudes which I believe what we call music normally belongs to, But constant-amplitude sound can also be music, can't it ? Sure, though I don't know any, I guess. Also it wouldn't be interesting to detect compression in it. The problem with calculating an average with peak amplitude is that peaks by definition occur only at certain points in time. A square wave is entirely made of peak points. What is it that makes you use such a flawed definition of peaks ? Yeah, that came out totally wrong. I was trying to say that often (you're correct: not always) the peaks themselves don't form a continuous signal by themselves. The continues signal that represents the 'peak' of the measured signal (think of a peak meter at a mixing desk) needs to be constructed. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] change in compression detection
On Tue, 2011-01-11 at 13:33 -0500, Mathieu Bouchard wrote: On Mon, 10 Jan 2011, Roman Haefeli wrote: Assuming that the more compression is applied, the more the RMS amplitude [1] approaches the Peak amplitude [2] of an audio signal, Why do you assume that ? Let's say I take a signal and divide it by its recent peak volume. The output of [osc~] will stay unchanged. A signal made of plenty of sharp spikes will have a much lower RMS/peak ratio and still be unchanged. Are you confusing this with waveshaping such as [expr tanh($v1)] ? It may be a special case of compression, but is not what is usually meant by that. http://en.wikipedia.org/wiki/Dynamic_range_compression I hope I'm not confusing dynamic range compression with wave shaping. Actually, depending on the compressor settings (short attack times, etc.) a dynamic compressor indeed acts a bit as a wave shaper. You mention constant oscillator signals as an example. On those a compressor wouldn't have (or only little, I should say in order to not contradict what I said above) any effect. Instead of constant amplitude signals think of signal with ever changing amplitudes which I believe what we call music normally belongs to, especially acoustic (as opposed to synthesized) music. Since compression/limiting allows to increase the RMS value of a signal without amplifying the peaks, I think compression decreases the difference between RMS amplitude and peak amplitude. The problem with calculating an average with peak amplitude is that peaks by definition occur only at certain points in time. In order to get an average you need a constant signal which is constructed by holding a reached peak value for a certain time and the slowly lowering the amplitude until a new peak value appears. Assuming that hold time usually is longer than one period of the measured signal, this would again decrease the difference between average peak amplitude and average RMS amplitude. Does that make sense? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] change in compression detection
On Sun, 2011-01-09 at 20:26 -0500, Mathieu Bouchard wrote: On Mon, 10 Jan 2011, ~E. wrote: I'm searching how i can detect the change in the compression of an audio signal. The purpose is to detect (and quantified) the compression changes between the music and the ads in a radioshow. Have any ideas ? If you don't have the original uncompressed recordings, I don't see how you could be doing that. You'd have to guess how complex sounds are supposed to fade out normally, to find out how much the fade out has been messed with. And then, in the compressor, you have both a measurement of input volume and a formula for turning that input volume into a gain to be applied, and both of those parts are subject to a lot of variation and tweaking. Assuming that the more compression is applied, the more the RMS amplitude [1] approaches the Peak amplitude [2] of an audio signal, you could measure the two and probably get a raw grasp how much compression was applied. This is simply an idea for which I don't have any reference that it is really working. I could imagine that recordings of certain sets of natural instruments show always a similar relation between peak and RMS amplitude for that set. However, usually there is already some compression applied when releasing the recording which makes it hard to distinct compression applied in the radio station from the compression shipped with the recording. I also could imagine, that it's much harder to find applicable rules for synthesized sounds. Roman [1] http://en.wikipedia.org/wiki/Amplitude#Root_mean_square_amplitude [2] http://en.wikipedia.org/wiki/Amplitude#Peak_amplitude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] news from the server admins
Many thanks for bringing it up again! Roman On Fri, 2011-01-07 at 20:28 +0100, IEM - network operating center (IOhannes m zmoelnig) wrote: as some of you might have noticed, puredata.info has vanished for some days, taking the mailing-lists and the website with it. the reason for the downtime was brutal aggression involving horrible things like rootkits and backdoors and whatelse. the never-sleeping puredata.info administration crew has worked countless hours (if not days) to restore the machine back to it's un-compromised state, and is happy to announce that hopefully the evil spores have been eridicated, the rootkits have been dismantled and backdoors have been locked for good. we also believe that the injection vector has been found and fixed. fgmasdr IOhannes PS: in any case, please refrain from attacking puredata.info in the future; the community's everlasting gratitude will be yours ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] timing
On Fri, 2010-12-24 at 07:23 -0500, Mathieu Bouchard wrote: On Fri, 24 Dec 2010, Roman Haefeli wrote: This also applies to [vsnapshot~] and I don't even know if that works correctly at blocksizes 64. Or even at blocksizes = 64 whenever a smaller-[block~]ed patch is inside a bigger-[block~]ed patch. (I think that this needs some repeating so that some people notice it) Yeah, thanks for pointing out. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] timing
On Thu, 2010-12-23 at 08:10 -0500, Mike Moser-Booth wrote: On 12/22/10 7:28 PM, Dietrich Pank wrote: thank you guys for your answers! I think I understand the basic theory. Experience is something else... e.g. line~ and metro doesn't work sample correct even in block~ size 1 vline~ doesn't work in block~ sizes 64 And even thresholds fastest response is 64, less block size doesn't increase it's quality. I'm baffled because I understood this object as gateway from audio back to event (sample count/analysis to trigger)... I have found this to be the case as well. It seems most (maybe all, not sure) signal-to-message objects have a minimum hard limit of 64 samples. Yeah, I don't know of any either. [bang~], [edge~], and [threshold~] I've noticed for sure are like this. I don't know about [vline~] since I use it to avoid having to change the block size. :-) I happily repeat myself: There is no need to adjust the block size when using [vline~]. See the attached patch. It's a (aliased) square wave oscillator built with [metro] and [vline~]. See that it works for any blocksize = 64 samples. As Dietrich already pointed out, for some reason it stops working as expected when using a blocksize 64. I don't why this is and I suspect it to be a bug. Roman #N canvas 556 260 270 350 10; #X obj 53 244 dac~; #N canvas 908 188 450 300 square~ 0; #X obj 53 103 metro 12; #X obj 53 143 f; #X obj 82 144 ==; #X obj 53 168 - 0.5; #X obj 53 208 vline~; #X obj 53 230 outlet~; #X obj 48 57 loadbang; #X msg 154 56 1000 \$1; #X obj 154 77 /; #X obj 154 32 inlet; #X obj 216 86 inlet; #X obj 216 169 block~; #X msg 216 137 set \$1 1 1; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 0 3 0; #X connect 2 0 1 1; #X connect 3 0 4 0; #X connect 4 0 5 0; #X connect 6 0 0 0; #X connect 7 0 8 0; #X connect 8 0 0 1; #X connect 9 0 7 0; #X connect 10 0 12 0; #X connect 12 0 11 0; #X restore 58 166 pd square~; #X obj 58 202 *~; #X obj 100 189 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 4 21 hsl 128 15 30 1000 1 0 empty empty empty -2 -8 0 10 -262144 -1 -1 8100 1; #X floatatom 22 46 5 0 0 0 - - -; #X msg 121 97 64; #X msg 178 97 1024; #X msg 60 98 16; #X msg 147 98 256; #X msg 91 96 32; #X text 123 189 - turn on; #X text 75 65 set blocksize; #X text 2 3 change frequency; #X obj 149 233 loadbang; #X msg 149 258 \; pd dsp 1; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 2 0 0 1; #X connect 3 0 2 1; #X connect 4 0 1 0; #X connect 4 0 5 0; #X connect 6 0 1 1; #X connect 7 0 1 1; #X connect 8 0 1 1; #X connect 9 0 1 1; #X connect 10 0 1 1; #X connect 14 0 15 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] timing
On Thu, 2010-12-23 at 13:12 +0100, Dietrich Pank wrote: I think I understand the basic theory. Experience is something else... e.g. line~ and metro doesn't work sample correct even in block~ size 1 Interesting. How did you test that? vline~ doesn't work in block~ sizes 64 I'm surprised. Again, how did you test it? good question :) patch attached. I'm afraid I didn't fully understand the idea of the patch. I mean, I understood the basic idea. But why are you assuming, that 2 samples and 3 samples are the smallest possible ramps that can be achieved with [vline~] and [line~]? Also I'm not clear, what kind of signal [vline~] and [line~] are supposed to produce. They don't accept the same message format. [vline~] takes up to three arguments (target value, ramp time, delay), while [line~] takes only two (target values, ramp time). Check the help file for the specifics. Anyway, your patch makes a few things quite clear. * Changing the blocksize for the [metro] / [metroplus] doesn't matter * The blocksize doesn't affect [vline~] as long as it is = 64 samples. * [line~] schedules ramps only on block boundaries, so when setting high blocksizes, one might has to wait a long time until it starts the ramp. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
