Re: [PD] Keeping Number box's
If you are using pd-l2ork, there is also universal preset system built into it using preset_hub and preset_node objects. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Phil Stone Sent: Monday, April 14, 2014 2:04 PM To: AP Vague; pd-list@iem.at Subject: Re: [PD] Keeping Number box's Or use the Number2 number box, and set its init attribute in properties. It will then init itself with the last value that was in the box at the time the parent patch was saved. On 4/14/14, 10:59 AM, AP Vague wrote: If you know exactly what you want the values to be before you open the patch you can replace the number atoms with messages, ie [32( instead of an atom. And then just send them a [loadbang] to initialize whatever they're going into... On Mon, Apr 14, 2014 at 1:47 PM, kate sweeney m.k.swee...@hotmail.com wrote: Hello, I am using GEM to create a graphical design video. I have completed a lot of it and have all my patches set up with the desired numbers etc. Yet everytime i close and re-open the project, all the numbers return to 0 which messes up my project big time. Is there a way to save the number box's as they are so they stay the same everytime the project is closed and re-opened? I have included a screenshot of before and after the project is closed and re-opened. Many thanks. ___ 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] Keeping Number box's
Also, FWIW, in pd-l2ork trigger can use static values, e.g. [trigger 1 b 0 blue] would output symbol blue from the rightmost outlet, then a zero, then a bang, and then a 1. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Pierrick Saillant Sent: Monday, April 14, 2014 2:02 PM To: pd-list@iem.at Subject: Re: [PD] Keeping Number box's Hello, You need to initialise the value. You can use the [loadbang] object to have a « bang » when your open your patch. And after use message box to set the different value. To have something better and to avoid problems its better to use a trigger to sequentialize the initialization. There is an example. Best, Pierrick Le 14 avr. 2014 à 19:47, kate sweeney m.k.swee...@hotmail.com a écrit : re a image001.png___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-l2ork release
Thanks for posting this Jonathan. The latest version is 20140402 (*03 for RPi build since it takes long to build). Most recently, a new way of highlighting invalid objects and comments in edit mode, bunch of lingering bug fixes pertaining to the new svg-based drawing of graphs, e.g. limiting what goes inside GOP to prevent questionable behaviors like scaling scalars but leaving objects inside unscaled, etc. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Jonathan Wilkes Sent: Wednesday, April 09, 2014 12:59 PM To: pd-list@iem.at Subject: [PD] Pd-l2ork release There's a new Pd-l2ork release: http://l2ork.music.vt.edu/main/?page_id=56 Here's my vague recollection of what's changed: * New preferences dialog that includes GUI settings, audio, and MIDI settings * GUI presets (canvas bg, xlets, Pd window, search window, etc.) * New Put menu array dialog with canvas and array properties in the same dialog * Color choices for array trace * Bar-graph array style * Ability to create scalars inside an object box * New [draw] drawing command for scalars: adds svg shapes rect, circle, ellipse, line, polyline, polygon, and path. (No text yet) * Affine transformations, opacity, stroke, etc. messages for new draw commands * New tutorials and demos for [draw] object * New image and sprite draw commands (alpha) * Improved search-plugin There are a lot more changes that Ivica made-- I'll let him comment on those. Best, Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-L2Ork [pd~] using real adc
Again, thanks for the report. I located the problem and fixed it in the latest git commit. Basically, it was a regression due to the new -unique flag that was added to startup flags to pd-l2ork that made it by default open all new patches in the existing instance, now it opens them according to the old rules ensuring that new instance invoked through the [pd~] external is always run with -unique flag. HTH On 04/01/2014 05:19 AM, pured...@11h11.com wrote: Hi, So for the [ii] I just added [init] somewhere and now all [ii] are found. No big deal! But I think I have found something a little bit more important (well for me at least): [pd~ start effectUnitOut.pd | [pd~ -ninsig 2 -noutsig 2 -fifo 2] the effectUnitOut.pd [adc~] is using my real adc (of my soundcard) and not the incoming signal~. hello bug: https://dl.dropboxusercontent.com/u/1455235/pdl2ork_bug.webm Btw multiple undo rules, à+ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd-L2Ork [ii]
Thanks for the report. It is possible that pd-l2ork is using an older version of iemlib as I've not synced that source in a while. Other option is that there is something potentially funny with the way externals are loaded. Let me investigate... Just to make sure, is ii an abstraction or an external and is it a synonym for init? -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of pured...@11h11.com Sent: Monday, March 31, 2014 4:44 PM To: pd-list@iem.at Subject: [PD] Pd-L2Ork [ii] When using [ii] in a patch, even with [import iemlib] - i have to use [init] once for [ii] to be found (need to save and reload the patch). ___ 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-L2Ork [pd~] using real adc
Thanks for the report. What is the exact expected behavior and what is inside the pd~ abstraction? BTW, I think the problem with the other issue is that ii is a synonym for init and I think I had this problem before where an object needs to be instantiated before its synonym is accepted. It may have been fixed upstream since the fork in which case I missed it. -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of pured...@11h11.com Sent: Tuesday, April 01, 2014 5:19 AM To: pd-list Subject: [PD] Pd-L2Ork [pd~] using real adc Hi, So for the [ii] I just added [init] somewhere and now all [ii] are found. No big deal! But I think I have found something a little bit more important (well for me at least): [pd~ start effectUnitOut.pd | [pd~ -ninsig 2 -noutsig 2 -fifo 2] the effectUnitOut.pd [adc~] is using my real adc (of my soundcard) and not the incoming signal~. hello bug: https://dl.dropboxusercontent.com/u/1455235/pdl2ork_bug.webm Btw multiple undo rules, à+ ___ 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] ANN: New Pd-L2Ork x86_64 and Raspberry Pi 20140319 release candidate
On 2014-03-22 17:03, Ivica Ico Bukvic wrote: Apologies for x-posting. i seem to remember that i have asked you this question multiple times in private, but never received an answer: is there *any* reason to make your announcements via pd-list instead of pd-announce [1]? all emails to pd-announce are forwarded to pd-list, but some people are only subscribed to pd-announce (as they are not interested in day-to-day discussion). ...IOhannes, indeed we've had discussions in the past to the point where I believe no matter what I do will be adequate in your eyes. Your replies to anything I post to this list teem with negativity, and a good portion of the time are off-topic (which makes me wonder how does that fit into the mailing list netiquette?). Yet, knowing you from our in-person conversations, I know you are a lot nicer than what your posts to this list make you look like. btw, anybody can post to pd-announce (all emails get manual moderation and are allowed if they are a proper announcement related to Pd somehow). And yet, I had those rejected as well, although I am not sure if pd-l2ork announcement is considered related to Pd... It is conceivably possible that this was a case of having bunch of mailing lists in the TO: header in the same email which is also known to land them in the admin pile (depending on the mailing list configuration), but given that all pd-announce emails are (AFAICT) moderated, what escapes me is why would one reject this merely on the principle and then in turn double the work both for the poster and themselves? (resending because apparently the original was rejected because I was not subscribed?...) no. it was rejected because the mailinglist has a built-in cross-posting reject rule. see [2]. First of all, if this is the case, then your mailing list is not configured properly as it is giving a report that is false/misleading. Second, I think if this is an automatic bounce, it should happen instantaneously (which was not the case). If it is left for review of list admins (and hence the delay in response), then the trouble you went to reject the post could've been simply redirected by seeing from who the email came and what its purpose is, rather than creating even more work for everyone involved. Sure, that introduces exceptions, but in the end I feel it is a nice way of showing appreciation for those who went through the trouble of contributing to the community as I am sure you'll agree writing an announcement and providing free online resources requires a lot more time than reading a subject and ticking the approve checkbox... I also think this is extraneous (assuming the reject is automated). Like yourself, I manage over dozen mailing lists among many other things that keep me busy and even I choose to keep those kinds of posts for review because I am aware people when they announce things don't want to send dozen same emails but simply one. At the same time, I also don't want to create extra work for you or anyone else, so to cut my monologue short, if you and/or the community so desire, I will stop posting any further announcements on any pd list, so as not to annoy you (and possibly others). After all, you manage the list, and life is too short to spend time arguing over things like these... Please understand I won't reply to any further discussions on this matter... Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GPIO, mcp3008 and Raspbian
Hi Ivica, I was working on a small external for MCP3008 using wiring pi, but I'd love to try yours if it is possible. Will it be possible to use it as an external like gpio with vanilla? are you using wiring pi for this? There is nothing in those externals to prevent them from being used in vanilla. They can be found in the root git/l2ork_addons/raspberry_pi/disis_gpio and disis_spi folders (latter is the MCP3008 one). Spi one does not rely on wiring pi. AFAIK wiringpi does not offer spi support but I could be wrong. Also, how are you getting the multiple pwm streams? I partially rely on wiringpi inside disis_gpio for software pwm on all pins (I say partially because wiringpi can only create a new thread for software pwm but does not offer ability to close the thread other than exiting the program, which is not an option for an environment like pd). So, each opened pin will have a separate high priority thread that gives you a 1000Hz PWM. disis_gpio also supports hardware pwm on pin 18 and that one has some kind of a logarithmic curve and as such behaves distinctly different but I simply did not want to go into anything higher than 1000Hz as that would choke the cpu. HTH best, J On Mar 20, 2014, at 1:16 PM, Ivica Ico Bukvic i...@vt.edu wrote: On 03/20/2014 12:37 PM, David Medine wrote: FYI There is also a RPi GPIO object for Pd by Miller Puckette here: http://msp.ucsd.edu/syllabi/206.13w/index.htm http://msp.ucsd.edu/syllabi/206.13w/index.htm and the same code with a makefile and build for UDOO here: https://github.com/cmuartfab/Udoo/tree/dem-rev/puredata/gpio https://github.com/cmuartfab/Udoo/tree/dem-rev/puredata/gpio I did see the note from garthz about the architecture collisions. I will attend to this. Anyway, make sure to use the gpio.l_arm version -- just delete the other two to avoid problems. Indeed, disis_gpio is loosely based on gpio. It however also offers things that gpio (AFAIK) doesn't, like multithreaded pusle-width-modulation (hardware on pin 18 and software on all pins) with an Arduino-like 0-1023 range. disis_spi is a completely new beast that allows interfacing with MCP3008 AD converter and provides up to 8 analog input channels that can provide high-resolution streams with values 0-1023. So, pd-l2ork externals essentially look to provide an Arduino-like environment. ___ 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 on Raspbian
There is also pd-l2ork for RPi. We are just readying a release with a comprehensive support for GPIO (including hardware and software PWM), as well as MCP3008 AD converter (for analog sensors). There is also a fairly detailed documentation on how to run RPi headless via a laptop, while sharing network connection. See: http://l2ork.music.vt.edu/main/?page_id=2288 HTH ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PD on Raspbian
On 03/20/2014 12:37 PM, David Medine wrote: FYI There is also a RPi GPIO object for Pd by Miller Puckette here: http://msp.ucsd.edu/syllabi/206.13w/index.htm http://msp.ucsd.edu/syllabi/206.13w/index.htm and the same code with a makefile and build for UDOO here: https://github.com/cmuartfab/Udoo/tree/dem-rev/puredata/gpio https://github.com/cmuartfab/Udoo/tree/dem-rev/puredata/gpio I did see the note from garthz about the architecture collisions. I will attend to this. Anyway, make sure to use the gpio.l_arm version -- just delete the other two to avoid problems. Indeed, disis_gpio is loosely based on gpio. It however also offers things that gpio (AFAIK) doesn't, like multithreaded pusle-width-modulation (hardware on pin 18 and software on all pins) with an Arduino-like 0-1023 range. disis_spi is a completely new beast that allows interfacing with MCP3008 AD converter and provides up to 8 analog input channels that can provide high-resolution streams with values 0-1023. So, pd-l2ork externals essentially look to provide an Arduino-like environment. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Bugs in Pd-Extended in Ubuntu LTS
Have you tested pd-l2ork? From: Pierre Massat [mailto:pimas...@gmail.com] Sent: Wednesday, March 05, 2014 3:03 PM To: Ivica Bukvic; pd-list Cc: Cyrille Henry; katja Subject: Re: [PD] Bugs in Pd-Extended in Ubuntu LTS Hi, Just a quick follow up on this topic. I have just compiled Miller's latest version (0.45-4), and the bug that's crashing X is still there. This time I managed to reproduce it somehow by creating an empty object to make a subpatch and typing pd m (and bang it crashed). Same behaviour with the same patch in pd-extended 0.43.4. It's super annoying... Cheers, Pierre. 2014-02-25 23:16 GMT+01:00 Ivica Bukvic i...@vt.edu: Once pd-extended removes unnecessary dependency on pd-utils you will. Until then you will need to uninstall one and install the other. On Feb 25, 2014 4:54 PM, Pierre Massat pimas...@gmail.com wrote: Hi, Katja, I will try to check if this is a problem with pulse audio. I also have a jackdbus running even when applications supposed to use it are closed (Ardour and Pd in my case). Can I install pd-l2ork alongside pd-extended, or do I have to uninstall it first ? Pierre. 2014-02-25 22:22 GMT+01:00 Ivica Bukvic i...@vt.edu: Guys, Can you check if pd-l2ork works OK and please report? We provide native Ubuntu builds (built for 12.04). On Feb 25, 2014 4:20 PM, katja katjavet...@gmail.com wrote: Hi Pierre, I'm on Xubuntu 12.04 with Pd-extended 0.44 and have experienced big troubles with Jack too. I only use Jack for complex routings like Skype to Pd or Kdenlive to Pd via PulseAudio+Jack. I got a lot of jackdbus-errors initially, and jack wouldn't restart. Don't know if it's the same issue which you're experiencing. Anyway, it seems that this was about jackd2 writing config files to different places, which can be out of sync under certain conditions. Not sure if this is a correct description but it is my interpretation. Looking at running processes in command htop, I always noticed a jackdbus processing still running when the dbus error was given. Killing the jackdbus process sometimes helped. But in the course of time I've somehow learned how to avoid it at all, by carefully considering the right order of operations when starting processes. I have PulseAudio disabled by default, so I can start Jack first, then the Jack clients, of which PulseAudio may be one. Then eventually the PulseAudio clients. When killing processes, everything in reverse order. I don't like this hocus pocus, but well, I'm happy if it works at all. On Kubuntu I couldn't get PulseAudio to cooperate with Jack. Katja On Tue, Feb 25, 2014 at 9:33 PM, Pierre Massat pimas...@gmail.com wrote: I just checked again and to to sum up I have three problems : - errors with JACK (and instability), - X crashes sometimes when typing stuff in an object box, - and Alsa throwing this error in the console : ALSA output error (restart failed): Broken pipe (though the sound does work). Pierre. 2014-02-25 21:23 GMT+01:00 Cyrille Henry c...@chnry.net: Le 25/02/2014 21:03, Roman Haefeli a écrit : On Die, 2014-02-25 at 19:50 +0100, Pierre Massat wrote: I have installed Pd-extended from the Ubuntu repos. It seems to be the same version as the one available on puredata.info (0.43.4). I am pretty sure there is no package called 'pd-extended' in the Ubuntu repositories. Probably you got it from Hans' ppa or from apt.puredata.info? Also, is your Ubuntu 12.04 up-to-date? Your bug description sounds like an intel driver bug in 13.04 or 13.10 that has been discussed a lot on this list. I thought this bug has been fixed for quite a while. i still have some problem. (i'm on 13.10). X can crash specially if i have object that are not created on the patch. c 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 ___ 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] libpd separating gui from core
For instance, it seems like there are two main concerns floating around: a) multiple instances of pd b) separating GUI from core I would add a c) here which is what pd-l2ork has been doing, namely getting rid of all known bugs and streamlining experience until it reaches a level of stability where issues are a rare occurrence. My take is that refactoring becomes a lot easier at that point because one will have a much better idea what components should look like. Otherwise, fixing things post-refactor will net in even more headaches where two parts may end-up being potentially out of sync with each other, resulting in a broken app. There are other suggestions like platform-specific vectorization and multi-threaded support, but if you try to do these at the same time, you reduce the chance of ever getting the code back into vanilla. They can be taken on after. IMO, the best thing to do going forward for a) would be to sync up with Miller and what he netted out with last time this was discussed ( see thread: http://lists.puredata.info/pipermail/pd-dev/2013-12/019702.html). It seemed like he was proposing to take a hefty chunk of the work on, or maybe if he is confident in merely the approach, someone else can have a go at it. Having been on this list for quite a few years, I know of only one person who was allowed to significantly contribute/alter the core and that was Hans. And even that amounted to mainly cleaning up tk code to make it more legible (yes, this is a gross oversimplification, there was internationalization, console verbosity, and many other little things, but in general the brunt of the work was lateral in nature). ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] libpd separating gui from core
From: Dan Wilcox [mailto:danomat...@gmail.com] Sent: Monday, February 24, 2014 11:34 AM To: Ivica Bukvic Cc: Jonathan Wilkes; pd-list@iem.at List; Peter Brinkmann Subject: Re: [PD] libpd separating gui from core On Mon, Feb 24, 2014 at 12:29 AM, Ivica Bukvic i...@vt.edu wrote: On Sun, Feb 23, 2014 at 11:04 PM, Dan Wilcox danomat...@gmail.com wrote: I consider that a sad thing. At least with Pd-extended, it was largely Pd-vanilla + externals. I don't think it needs to be sad. Yes, pd-extended is pd-vanilla + externals + most limitations of the vanilla. How does that help you in your mission to move forward? I think you're missing my point here. With Pd-extended, you know you would make things which would work with Pd-vanilla if it had the appropriate externals compiled and available. With Pd-L2ork, there's a good chance that will not be the case as you move forward, thus fragmenting people between the apps. The Linux distro analogy is not a very apt one as there are far fewer PD users by comparison. But what if breaking things will bring more people in? (I ask this fully realizing I am playing a devil’s advocate here since I have no proof of this being the case with pd-l2ork nor that this will ever be even remotely close to the success of libpd) I'm not saying it *will* happen or that it's your stated goal to split things, I'm just trying to suggest again that there could be a middle ground that could work for both Miller's and the communities goals. Other projects have managed that, why can't ours. Obviously, trying to push all updates and requirements back to the source have not worked, but maybe we can decided upon a subset of things that could/should be in the core and find a way to implement them. Again, I think gui abstraction could be a way to help this. I respect what y'all are doing with Pd-L2ork. It looks really awesome. I also know you've been trying to integrate changes back into the Pd-vanilla. I just think that there must be another way. I am all ears :-) That said, I would love to entertain the thought of co-developing libpd but I think that is currently bogged down by the same predicaments that pd-extended and any other non-vanilla implementations have to deal with, which is whether you keep the backwards compatibility or move forward as fast as you can at the expense of the compatibility. Which is why I bring up the idea that we find some firmer ground in the bog and reach a compromise instead of forking galore. If fragmentation is a good thing, then there really isn't much of a community, simply a few islands rehashing the same things on a roughly a 5 year cycle. I'm sure you'll keep PD-L2ork going and it won't go the way of DD, but again there should be a way to have our cake and eat it too. I don't see the harm in trying. Also, I'd like to point that, bogged down or not, libpd has IMO sparked the most life into Pure Data over the last few years by bringing lots of new people in who want to patch for phones and apps embedding libpd. Alot of those people are Max users ... :D I personally don't like the idea of us working on libpd when you take off with Pd-L20rk and we might reach a point where we'd want a libpd-L2ork. Would be nice to have both ... A lot of things would be nice but that is not the reality of the current situation. I think backwards compatibility is even less relevant to libpd when it is embedded in ways that are completely transparent to users, but I guess I digress, so I'll shut up. Less relevant? The libpd code is Pd-vanilla. It already works and is backwards compatible. This way at least you know that if it works in Pd-vanilla when patching it will work in libpd. Should we diverge to make custom changes we need and then require an entire new gui for people to build patches for libpd only? As it is now, libpd development is largely pd development and that's a good thing overall. If we can manage the architectural changes that were required for libpd (by Peter Brinkmann), then I don't see why we can't find a reasonable way to integrate some of the things that are needed for more advanced guis etc. The rest can be modular in tcl/tk and externals. I'd love to use Pd-L2ork, but how long will it be compatible with libpd? I don't want to build a bunch of patches around new functionality that just won't work on a mobile phone and would be harder to debug. If the reality is as you say, then I'm not really interested in spending my time hacking on our little island. And the only thing I can say at this point is that I respect that and to thank you for your genuine effort at moving the community forward. That remake was hasty of mine and short sighted. My background is in engineering and I hate seeing effort split up and duplicated on things that we all want/need. If we all respect Miller, maybe we can also respect that we could find a middle ground with
Re: [PD] Pos1 and End in keyboard editing
In pd-l2ork you can do that and also use ctrl+home/end (or arrow left/right) to navigate between spaces inside a multi-arg text, as well as between multiple lines of comments for instance, since pd-l2ork also supports saving endlines inside comments. HTH From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Brian Fay Sent: Friday, February 14, 2014 6:52 PM To: Peter P. Cc: pd-list Subject: Re: [PD] Pos1 and End in keyboard editing It's been like that for as long as I can remember, and I hate it!!! I've just assumed it was some tcl/tk quirk that has kept it from being changed, but I really don't have a clue as I have no desire to learn tcl/tk... -Brian On Fri, Feb 14, 2014 at 4:43 PM, Peter P. p8...@aol.com wrote: Dear list, this has probably been discussed already (didn't find sth after a quick search in the archive though): When using the computer keyboard's Pos1 and End keys to jump to the beginning of an object or numberbox when editing its contents, will make the cursor move there, but upon typing new characters, it jumpes back (or never really moved away) from its original position. This is Pd-0.45.0 vanilla from Miller's git and tk8.5/tcl8.5 (in fact 8.5.14-2) on a Debian system. does anyone else experience this too? best, P ___ 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 freeze with error message(Tcl)
I've seen these also happen when something tries to address a non-existent
widget (e.g. when it is being closed or something similar). There is an easy
way to prevent this from ever stopping GUI from working by encapsulating all
commands streaming from pd-gui with a simple catch{command}. This is what
in part pd-l2ork does and I cannot remember when was the last time I had a
problem like this.
-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
Miller Puckette
Sent: Wednesday, January 29, 2014 12:29 AM
To: Jonghyun Kim
Cc: pd-list@iem.at
Subject: Re: [PD] Pd GUI freeze with error message(Tcl)
Hi Jong -
I think the *(Tcl) INVALID COMMAND NAME' stuff isn't related to Pd
freezing,
but I'd like to find out how it happens and fix it.
The GUI can freeze if Pd is overloaded with audio computation on Mcintosh
compuers - the only thing I can suggest is reduce the amount of audio
computation (I know - nobody would ever want to do that :)
cheers
Miller
On Wed, Jan 29, 2014 at 04:03:17AM +0100, Jonghyun Kim wrote:
Hi list,
I don't know why this cause, but sometimes it appears and GUI freeze,
but
still Audio alive. Only GUI die...
Number Box, Vu meter, Sliders, and so on, these GUIs all stop, and
don't
show the actual numbers...
Anyone knows this issue?
--
*(Tcl) INVALID COMMAND NAME: invalid command name .x4de9a0.c*
*while executing*
*$tkcanvas itemconfig $tag -text $text*
*(procedure pdtk_text_set line 2)*
*invoked from within*
*pdtk_text_set .x4de9a0.c .x4de9a0.t395fcb0{98.13}*
*(uplevel body line 19)*
*invoked from within*
*uplevel #0 $docmds*
--
Pd-0.45-4 (32bit)
Mac OS X Mavericks
Screenshot attached.
Thanks,
Jong
___
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] error on canvas while writing in object : tcl error: wrong # args: should be pdtk_canvas_sendkey name state key iso shift
Hi, This is because pd-l2ork has recently introduced a way of filtering autorepeat keys so that [key], [keyup], and [keyname] objects only report real key presses (as they should) while other forms of key input (e.g. writing into an object box) still obey the autorepeat. This had to be done in a way that breaks pdtk_canvas_send_key by adding an additional variable and hence library like gridflow that hasn't kept up with pd-l2ork's updates is no longer functioning as it should. Adapting this to pd-l2ork should not take much of an effort--it is just a question of time and who will do it. HTH Best wishes, Ico On 01/12/2014 09:01 AM, t'es in t'es bat wrote: hello, this bug now crash pd ... If i try to type in an new message or if i try to just put a new object. I'm using pd-l2ork and mint olivia base on ubuntu 13.04/raring so... any ideas... Happy new year again... david TNTB P/: 06 86 86 12 19 SKYPE/: tntb.net http://tntb.net | http://www.tntb.net http://www.databit.me http://www.circuitpixel.net /_?_??_? ???_?? _ __?_??? ?__?_??_? ???_?? _ __?_??? ?__?_??_? ???_?? _ __?_??? ?__?_??_? ???_?? _ __?_??? ?__?_??_ 2014/1/12 t'es in t'es bat tesintes...@gmail.com mailto:tesintes...@gmail.com Hello, Happy new year... i'm just working for few weeks with pd-L2ork today i compile gridflow from svn and now i'can't type text in canvas it works on tcl console or in other place in the software but impossible in canvas. It's like the keyboard doesn't work... each character return a: tcl error: wrong # args: should be pdtk_canvas_sendkey name state key iso shift so what can i do ...? David TNTB P/: 06 86 86 12 19 tel:06%2086%2086%2012%2019 SKYPE/: tntb.net http://tntb.net | http://www.tntb.net http://www.databit.me http://www.circuitpixel.net /_?_??_? ???_?? _ __?_??? ?__?_??_? ???_?? _ __?_??? ?__?_??_? ???_?? _ __?_??? ?__?_??_? ???_?? _ __?_??? ?__?_??_ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be pdtk_canvas_sendkey name state key iso shift
I tried in the past overloading things on tcl/tk side of things but that did not work out all that well. In this case, however, it is not practical to do so as the original implementation is inadequate to address the problem at hand and maintaining bunch of workarounds is simply too time consuming to push the project forward at a desired pace. I think this is pretty much the reason why pd-l2ork exists. Pd-l2ork's philosophy is that it will maintain backwards compatibility as long as that does not require maintaining something broken/limited and whose workaround would result in way more overhead than it would to address the third-party libraries that rely on this. In this case it is AFAICT only Gridflow that does this and it has not been updated in quite some time (please correct me if I am wrong). HTH Best wishes, Ico From: Dan Wilcox [mailto:danomat...@gmail.com] Sent: Sunday, January 12, 2014 7:19 PM To: Jonathan Wilkes; Ivica Ico Bukvic Cc: pd-list@iem.at List Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be pdtk_canvas_sendkey name state key iso shift It's not possible to overload the function? aka 1 that takes 5 args and another that takes 7? From what I can tell, the usual style within the pd core has been to add new args to the end so that backwards compatibility isn't sacrificed. Then again, I don't know the details in this case ... With libpd, so far, we've avoid trying to make any large, incompatible changes to the core. Mainly, at least IMO, because we do not want to end up diverging to the point to where we'll never be able to get said changes upstream. At this point, I'd love to sit down with a bunch of you and work out a proposed roadmap to separating gui pd core so that libpd could become the standard core between flavors. I haven't delved into the core enough to know if that is a foolish idea, but it really seems like a great idea to standardize some of the functionality ... On Jan 12, 2014, at 5:55 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: Re: [PD] error on canvas while writing in object : tcl error: wrong # args: should be pdtk_canvas_sendkey name state key iso shift Date: January 12, 2014 at 5:54:49 PM EST To: pd-list@iem.at On 01/12/2014 10:55 AM, Ivica Ico Bukvic wrote: Hi, This is because pd-l2ork has recently introduced a way of filtering autorepeat keys so that [key], [keyup], and [keyname] objects only report real key presses (as they should) while other forms of key input (e.g. writing into an object box) still obey the autorepeat. This had to be done in a way that breaks pdtk_canvas_send_key by adding an additional variable and hence library like gridflow that hasn't kept up with pd-l2ork's updates is no longer functioning as it should. Adapting this to pd-l2ork should not take much of an effort--it is just a question of time and who will do it. But notice the error tells the user that the proc expects five args, and not seven args like your revision of pdtk_canvas_sendkey. This is because matju told Gridflow to steal the pdtk_canvas_sendkey proc and renamed it to pdtk_canvas_sendqui (which is pretty funny in itself), and then it sends tcl a brand new pdtk_canvas_sendkey proc with 5 args and code that presumably has to do with unicode support. I say that because you can find it in the Gridflow source file named unicorn.cxx (which is also funny in itself). So if you can figure out what it's doing, you can try to merging it into Pd-l2ork or at least make it compatible with it. But there are probably several other places where matju drilled into Pd's walls from the outside, and they probably conflict with Pd-l2ork's renovations. (Probably the widgetbehavior struct and comment struct conflict.) -Jonathan Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] please post: announcing Operacraft premiere
Apologies for x-posting... It is my pleasure to announce tonight's premiere of OPERAcraft. Hosted by Virginia Tech's Institute for Creativity, Arts, and Technology, in collaboration with the School of Performing Arts (SOPA), and Linux Laptop Orchestra (L2Ork), this week will feature a premiere and a second performance of a newly produced opera. While both events are sold out, they will be also streamed live online (please see below for a link and additional info). OPERAcraft couples traditional opera with a custom mod of ubiquitous Minecraft designed at Virginia Tech specially for this purpose. Using Linux Laptop Orchestra's pd-l2ork software Minecraft's custom mod is transformed into a full-fledged staging environment, with animated character mouth movement driven through pd-l2ork's speech analysis engine, hand and body gestures, multiple camera angles, camera view mixer, subtitles, behind-the-scenes performer warnings, and a full scene control (fadeouts, transitions, etc.). A 20-minute opera titled The Surface: a world above is desiged by and large by high school students, including story, libretto, costume and set design. The project is directed by Prof. Ariana Wyatt, Virginia Tech School of Performing Arts' voice faculty. The music is an adaptation of Mozart's arias performed by Virginia Tech School of Performing Arts' piano faculty Dr. Tracy Cowden. Operacraft mod and supporting pd-l2ork infrastructure was imagined and designed by Virginia Tech School of Performing Arts' and ICAT computer music faculty Dr. Ivica Ico Bukvic and devised in collaboration with Virginia Tech Computer Science undergraduate student Cody Cahoon. For additional info visit: Virginia Tech Center for the Arts Page: https://www.artscenter.vt.edu/Online/ (click on Performances Events - Other Events) Virginia Tech Institute for Creativity, Arts, and Technology http://www.icat.vt.edu/funding/operacraft Livestream (December 4th 730pm EST, December 7th 2pm EST): https://new.livestream.com/operacraft L2Ork and Pd-L2Ork: http://l2ork.music.vt.edu http://l2ork.music.vt.edu/main/?page_id=56 Best wishes, -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork on mint olivia need advices
Great! Do you even need to compile pd-l2ork? Why not simply installing the deb provided on L2Ork’s website? My understanding is Mint has the same if not newer version of dev tools found in Ubuntu, so you should be able just to run that package. HTH Best wishes, Ico From: t'es in t'es bat [mailto:tesintes...@gmail.com] Sent: Wednesday, November 27, 2013 5:41 AM To: Ivica Bukvic Cc: pd-list Subject: Re: [PD] pd-l2ork on mint olivia need advices Hello, i look around my problem. It was a apt pkg problem. I find a solution there : http://askubuntu.com/questions/140246/how-do-i-resolve-unmet-dependencies sudo apt-get clean then sudo apt-get -f install Then run: sudo dpkg --configure -a Then run this again: sudo apt-get -f install for more advice follow the links it'll be better... After i need to install : ppa:xorg-edgers/ppa with sudo apt-add-repository ppa:xorg-edgers/ppa and i succeed to run sudo apt-get install libgl1-mesa-dev libglu1-mesa-dev libglew-dev libftgl-dev libquicktime-dev and it works... so now i will compile the pd-L2ork Nextr episode... TNTB P/: 06 86 86 12 19 SKYPE/: tntb.net | http://www.tntb.net http://www.databit.me http://www.circuitpixel.net /_̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_ 2013/11/26 Ivica Bukvic i...@vt.edu Without seeing the errors and knowing your setup it is difficult to say. If Mint is anything like Ubuntu then you may need to enable additional repositories. In Ubuntu they are called universe and you may possibly even need to enable multiverse. You may also encounter errors related to packages that are not signed or repositories that are not signed. Assuming that you're using default repositories this typically should not be a problem but again I don't know what your situation is because I don't have enough information to say one way or the other. Hope this helps! On Nov 26, 2013 4:02 PM, t'es in t'es bat tesintes...@gmail.com wrote: hello i'd just check and i find all the packages in synaptic but if i try to select for install i got a message saying package not certified, risk of attack from bad people or something. If i ckeck for install the package become red and i got a broken package message... It seem to be a problem with my system ? Impossible to get the mesa-dev or quicktime-dev package... so what can i do ? thanks TNTB P/: 06 86 86 12 19 tel:06%2086%2086%2012%2019 SKYPE/: tntb.net | http://www.tntb.net http://www.databit.me http://www.circuitpixel.net /_̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_─ ̲̲͋_̲̅ _ _̲̅̅̅_̅_̲̲̅ ̲__̲_̲̅_ 2013/11/26 Ivica Bukvic i...@vt.edu Ugh, just read the rest of your message. I guess we need to investigate what are the exact package names for Mint and rebuild the package to for Mint format? Can you list what packages are missing and what are the closest package names you have in synaptic? Thanks! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Help with OSX App minefield
But the Pd dev community has always been not so good at coordinated efforts. There is a history of lots of effort going into semi-compatible dev forks which mostly die out after a run (pd-devel, desiredata, vibrez, etc. etc.) Perhaps Pd- extended or pd-l2ork will be the next one to die out... .hc Hans, Your heart is in the right place but we also need to practice what we preach. I think the FOSS community's greatest weakness is also its greatest strength--if things die away and even get duplicated, they have done so for a specific reason. I find the existence of pd-l2ork essential in what I do as I am sure you and many others find pd-extended and/or pd-vanilla. Just like Miller, you, I, and many other core contributors to the Pd ecosystem, I am flattered that others may find my flavor useful but I have no intentions of trying to make anyone a convert. In other words, having options is a good thing and we all ultimately choose to use whatever best addresses our needs, even if that means introducing a level of redundancy. Our projects have also inspired each other on various occasions and I see this as a good thing--at the very least I see this as a great source for motivation. I have no intentions of dropping pd-l2ork anytime soon because it has proven particularly useful in my own work. And even if one day I do stop developing it, I have no expectations about its future. Ideally, someone else will pick up the code and run with it. And if no one does I guess that will be the testament to how bad this branch was and maybe it will be a good thing that it will wither and die away. OTOH, it may persist and transform into something none of us could ever even imagine, and that is fine as well. Ultimately, pd-l2ork serves my purpose (just like I anticipate pd-extended serves yours) and is IMO different enough in its agenda/focus to warrant its existence--and as long as that continues to be the case I am fairly confident that we'll all continue plugging away at that next iteration of our preferred platform. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [path] external
Does anyone know where is the [path] external's source located (the one that has a help file in 5.reference/path-help.pd)? The PD_META suggests it is an internal object but I could not find any trace of a gensym(path) in the source (or in the externals folder for that matter). Any help that can resolve this mystery is greatly appreciated! -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [path] external
On 11/02/2013 10:16 AM, Ivica Ico Bukvic wrote: Does anyone know where is the [path] external's source located (the one that has a help file in 5.reference/path-help.pd)? The PD_META suggests it is an internal object but I could not find any trace of a gensym(path) in the source (or in the externals folder for that matter). Any help that can resolve this mystery is greatly appreciated! Never mind, apologies for the noise--it appears that a script overwrote PD_META and provided incorrect information. Is it safe to assume that classpath has replaced path at this point (they look identical in their behavior)? -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] trouble with comment in graphique
Hi Olivier, I presume you're talking about the comment object not saving manual end-lines. If that is so, this is a common limitation. One way to work around it is to create multiple comments, one for each line. Another is (assuming you're on Linux) is to try pd-l2ork where comments support manual end-lines. HTH Best wishes, Ico -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Olivier Baudry Sent: Friday, October 18, 2013 9:53 AM To: pd-list@iem.at Subject: [PD] trouble with comment in graphique Dear all There is bug with comment Steps to reproduce 1) Open patcher 2) Create graphique 3) Open graphique 3) Write comment vertically like R M O D s 4) close graphique 5) Save Main Patcher 6) Comment take horizontal position ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Direct-from-disk audio with position, loop, varispeed
Hey, you are right, there should be a packaging, or integration into pd-extended - but actually, i am not currently maintaining my externals at all because of a serious lack of time. They just work (or they don't). I have tried for years, but no one seems interested in volunteering to package or integrate flext and flext-based externals (xsample, py, dyn~, pool, fsplay~, clk, zeroconf and many others) for more general use. FWIW, flext lib and a few externals are a part of auto-building script in pd-l2ork. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] $1 inside a message is not saving data ?
I found that in PD-extended 42.5 - the $1 inside a message is not saving
data. Is it a bug ? see patch below.
no, it's expected behaviour and has been like this since forever.
a $arg in a messagebox will always be replaced according to the incoming
message. it doesn't have a memory.
...
A programming language is a lot about being consistent, and as such it seems
logical that a msg should retain its last known state, so that when receiving a
bang it would output its last stored values. msg certainly stores the remainder
of a non $arg list (if any) and even saves it with the patch, so I would argue
that it very much has a kind of memory that can be altered with [set{.
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] $1 inside a message is not saving data ?
and as such it seems logical that a msg should retain its last known state, no. that's totally unrelated to being consistent. so that when receiving a bang it would output its last stored values. why? i think the current behaviour is very consistent though probably less convenient than some would like to have it. ...how is [$1] retains value and [msg] doesn't (except it does anything other than $n) consistent? As you said, it's consistent in terms of having been Pd's dollarsign behavior forever. Outside of that specific type of consistency across time-- i.e., backwards compatibility-- I see no valid argument that either way is more consistent. Both approaches are self-consistent. They (presumably) work exactly the same regardless of the context in which they get used in a particular patch. Nevertheless, I think backwards compatibility is important. Here, the current argument out of range error gives helpful clues to patching mistakes. With Ivica's system if you set that out-of-range argument a single time then future mistakes that result in too few args to the message box would go unnoticed. (They'd get padded with the old value.) Then, there are those situations where properly formed message is passed through the msg object with no reported errors but is still malformed according to the receiving object below msg. An error is thrown by the receiving object but one has no way of recreating and studying the offending message... Another thought is that just like [$1] retains last data value during runtime, shouldn't [msg] too? After all [msg] retains the rest of the list inside it not only during runtime but also during save, so why would not it retain its last data during runtime? Ico -Jonathan ___ 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] ANN: pd-l2ork v.20130920 released
See here: http://disis.music.vt.edu/pipermail/l2ork-dev/2013-September/000440.html HTH From: Ivica Bukvic [mailto:i...@vt.edu] Sent: Monday, September 30, 2013 9:00 AM To: Mario Mey; pd-list Subject: Re: [PD] ANN: pd-l2ork v.20130920 released Look for Albert's email on L2Ork-dev making list. HTH On Sep 30, 2013 8:57 AM, Mario Mey mario...@gmail.com wrote: Searching for libstk, libstk0-dev appeared to install. But I couldn't install it, because it needed libstk0c2a (= 4.4.3-2) . I installed it... but, libstk0-dev still ask me for that dependency. It's strange. Anyway, I would like to try it, but I have not so much time to spend in installing. Now I'm googling for Albert Graef builts. If I have no luck... maybe I try again some day in the future. Thank you! El 25/09/13 09:06, Ivica Bukvic escribió: Can you check if you have any libstk packages available in the software center? Also make sure that you have universe repertories enabled. Btw what version of Ubuntu are you using? Albert Graef has a launchpad with all these packages built for newer versions of Ubuntu. HTH On Sep 25, 2013 8:01 AM, Mario Mey mario...@gmail.com wrote: I would like to try pd-l2ork... but, when I try to install .deb, Ubuntu Software Center tell me that it couldn't find libstk0-dev. When I try to install it, in Synaptic, the installation ask me to uninstall almost my audio applications. I remember something like this when I tried to change Jack version. Could this be? I use jackd (Jackdmp, I think...) El 23/09/13 09:26, Ivica Ico Bukvic escribió: As usual, apologies for x-posting... It is my pleasure to announce the latest release of pd-l2ork free open-source visual programming language for interactive media, and supporting K12 educational module for the 32-bit and 64-bit Linux, as well as Raspberry Pi (Arm) platforms. pd-l2ork is the infrastructural backbone of Virginia Tech DISIS Linux Laptop Orchestra (http://l2ork.music.vt.edu). Highlights include: *Ported all vanilla GUI objects and events to cairo-based SVG-like tkpath canvas providing antialiased drawing capabilities, bezier patch cords, and setting stage for a zoomable canvas *Implemented a new scrollbar system using semi-transparent objects right on the canvas *Implemented filtering of autorepeat keyboard events for key, keyup, keyname objects *Expanded K12 library with numerous improvements and added a couple demo files *Backported resizable objects and recent files *Implemented native drag-n-drop *Improved GUI appearance *Began porting 3rd party objects to new cairo-based canvas (non-accelerated 3rd-party objects can be recognized by having a blue selection box and their considerably slower redraw) *Cleaned-up extended pddp documentation and added comprehensive cyclone documentation *Began filtering (disabling) building of redundant externals within the cyclone and other 3rd-party libraries *Proper visual reordering without the potentially cpu-expensive canvas_redraw for all accelerated objects (non-accelerated 3rd-party objects can be recognized by having a blue selection box and their considerably slower redraw) *Disabled drawing of redundant nlets for objects embedded inside a GOP object (for Max users, equivalent to a bpatcher) *Embedded tkdnd and tkpath libs directly into source for a monolithic build; made several improvements to the tkpath lib fork *Many other minor bugfixes and improvements (see Changelog for more info) A screenshot of the K12 module is attached. Alternatively, it can be found at: http://puredata.info/downloads/Pd-L2Ork/releases/20130920/screenshot/image_v iew_fullscreen Complete Changelog: http://puredata.info/downloads/Pd-L2Ork/releases/20130920/ Download Links: Binary Builds Documentation: http://l2ork.music.vt.edu/main/?page_id=56 Source: http:///github.com/pd-l2ork/ http://github.com/pd-l2ork/ Best wishes, -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 tel:%28540%29%20231-6139 (540) 231-5034 tel:%28540%29%20231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] prevent opening of patches
FWIW, the latest pd-l2ork release has a -unique flag (disabled by default) so whenever you open a new file by double-clicking inside a file browser, it will open it inside an existing instance (if any) or spawn a new instance (if none). Spawning instances with -unique flag will force creation of a new instance. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Marco Donnarumma Sent: Sunday, September 22, 2013 7:14 AM To: pd-list@iem.at Subject: Re: [PD] prevent opening of patches That's useful, but up until recently you had to create a second instance of Pd from the command line anyway, since OSX would show you the instance you already had if you tried to open it from the operating system. Or...have I missed the point? My friend and collaborator always needs two Pd's, one for Gemnotes and one for audio processing, to play my musioc...and we wrote a BASH script to launch the gemnotes one after the audio one was set up. well, personally most times, when developing, I need to create abstractions and use global variables just to experiment with stuff. And if two instances of Pd are opened when you don't want it, it can be very annoying. Even worst scenario when you are teaching, student might open 4 patches at a time, and as 4 Pd instances are launched, and it's a mess. I always wondered whether we could have a flag in Pd GUI that set this kind of configuration. Like, always open a new Pd instance, always use one Pd only... something like that. imho it would be useful. cheers, M ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Finish Him!
:-D From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Dan Wilcox Sent: Tuesday, September 03, 2013 12:18 AM To: pd-list@iem.at Subject: Re: [PD] Finish Him! I don't think it's possible to get nerdier than that. :D GetOverHere On Sep 2, 2013, at 11:52 PM, pd-list-requ...@iem.at wrote: From: Jonathan Wilkes jancs...@yahoo.com Subject: [PD] Finish Him! Date: September 2, 2013 11:51:50 PM EDT To: pd-list@iem.at pd-list@iem.at Reply-To: Jonathan Wilkes jancs...@yahoo.com Here's some more [drawimage] fun: http://puredata.info/Members/jancsika/subzero.webm/view -Jonathan Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Upcoming pd-l2ork release teaser
On 08/27/2013 04:09 PM, Jonathan Wilkes wrote: On 08/27/2013 12:20 PM, Ivica Ico Bukvic wrote: We are coming up on a new pd-l2ork release--one that I am particularly excited about. As I continue to put on the finishing touches, I wanted to share a small but hopefully sweet teaser screenshot with everyone :-) Very cool. Is this using tkpath? Yep :-) It's been quite an overhaul, however, far from a simple drop-in replacement to get this but I think it's been totally worth it. Best wishes, Ico -Jonathan Cheers! ___ 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 -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Upcoming pd-l2ork release teaser
We are coming up on a new pd-l2ork release--one that I am particularly excited about. As I continue to put on the finishing touches, I wanted to share a small but hopefully sweet teaser screenshot with everyone :-) Cheers! -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net attachment: pd-l2ork_teaser.png___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] CPU usage of GUI objects in subpatches
Mapologies. What I mentioned was meant for pd-l2ork. Not sure about the others. Best wishes, Ico -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Frank Barknecht Sent: Monday, July 15, 2013 9:13 AM To: pd-list@iem.at Subject: Re: [PD] CPU usage of GUI objects in subpatches Hi, I didn't test current Pd versions nor your fork, but up to 0.43 GUI objects in subpatches or abstractions were a substantial and significant CPU load when they are activated, even when invisible. So this is slow: [r data] | [hsl ...] | [s data-out] But this is fast: [r data] | | [hsl ...] |/ [s data-out] Maybe this has changed now with the latest versions, so I would recommend to benchmark it again. Ciao -- Frank On Sun, Jul 14, 2013 at 12:16:24PM -0400, Ivica Ico Bukvic wrote: AFAIK none--if it is not visible, its gui calls are ignored. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of i go bananas Sent: Sunday, July 14, 2013 4:01 AM To: PD List Subject: [PD] CPU usage of GUI objects in subpatches I'm assuming of course that no GUI objects in subpatches is optimal. but what sort of effect do sliders. toggles, bangs, etc have on CPU usage when hidden in unopened subpatches? ___ 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] CPU usage of GUI objects in subpatches
AFAIK none--if it is not visible, its gui calls are ignored. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of i go bananas Sent: Sunday, July 14, 2013 4:01 AM To: PD List Subject: [PD] CPU usage of GUI objects in subpatches I'm assuming of course that no GUI objects in subpatches is optimal. but what sort of effect do sliders. toggles, bangs, etc have on CPU usage when hidden in unopened subpatches? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On 07/03/2013 04:31 AM, Roman Haefeli wrote: On Wed, 2013-07-03 at 03:56 -0400, Ivica Bukvic wrote: I guess we need to clarify what not usable at all means. If a patch works but one optional gop hsl is not visible, personally I would say that one element may not be usable and only temporarily. Many of my patches are not usable at all without GOP GUIs visible. And I cannot fix it myself as either it breaks pd-vanilla|pd-extended or pd-l2ork or it looks dead ugly. So yes, it breaks compatibility in a serious way. And I also do not see the temporary aspect of it. I as a patch developer can't provide a solution to this. This is _the_ reason I don't even try to bother to make my patches work in pd-l2ork. And I even need to tell people that they shouldn't use pd-l2ork when they want to use my patches. The solution is the one you stated above--stick to one particular flavor of pd and run with it. I for one believe the sooner I switch my patches to a more consistent drawing mechanism the less I will have to deal with down the road. pd has two choices: 1) keep the same inconsistent behaviour for as long as it exists causing problems in other places for the patch developers such as yourself (e.g. autopatching), in the end causing the same amount of work (whether you fix whatever is currently misaligned or do that while patching because your autopatch feature did not align your objects properly is as far as I can tell the same amount of work, of course, assuming that you do use autopatch--I do, so this is very important to me) 2) fix this at some later date at which point you will have a larger library of patches you've built between now and that later date that will require fixing because they relied on the current inconsistent way Consider also how pd does not properly account for labels on iemguis or comments and does not mind having them stick outside GOP. Or how dynamically changed iemgui objects inside GOP do not get their visibility rechecked to see if they still fit within GOP and then spill outside it only to disappear when you copy and paste the said GOP. These are all fixed within pd-l2ork. I believe these are very pressing issues for me as L2Ork's entire GUI scoring system is built around iemguis and scalars and I want to make sure that others developing similar scores (or expanding upon the existing) for the ensemble do not encounter such inconsistencies that can be abused for temporary solutions that later break because such bugs have been fixed, rendering their scoring engine unusable. tl;dr version: I find issues of GUI inconsistency critical and prefer to fix them sooner rather than later and do not want to worry about legacy behaviour that is incorrect to begin with, because the longer one waits, the more they'll have to fix later when the similar/identical fix is implemented in their flavor of pd. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
On 07/02/2013 06:54 AM, András Murányi wrote: Very good idea, thanks Roman! Some difficulties I'm having: - I don't know how to set the label of [cnv]... is it possible at all? - (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP). Thanks for reporting this, András! hslider, vslider, and vumeter had indeed had incorrect getrect calculation for the bottom-right corners inside GOP (vu also had incorrect top). This has been fixed and committed a couple minutes ago into git. Binary builds of the new version forthcoming. Best wishes, -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GOP text field / symbol which is resizeable? (was: GOP text field which sends bang?)
[symbol\ | [label $1( | [cnv] - (ATTN: Ivica) [hsl] seems to have the bounding box (?) miscalculated in l2ork so it doesn't GOP when it's less than 2-3px from the border of the parent canvas. Checked in Vanilla, it works as expected ([hsl] can be placed to the very border and it will GOP). According to Ivica this is on purpose. The reason is that iemguis used to have miscalculated positions and pd-l2ork fixed that while pd-vanilla/pd-extended didn't. Unfortunately, this breaks compatibility between pd-l2ork and pd-vanilla/pd-extended. Roman This is true. Although, I wouldn't call translating an object by 3 pixels exactly breaking compatibility. I do agree it is a nuisance nonetheless, yet I feel it is a necessary part of pd(-l2ork) growing and becoming more consistent. The reason why I did what I did in pd-l2ork is best portrayed if you use autopatching option which positions everything in line vertically. If you autopatch objects like atom, then hsl, then another atom (or symbol or simply an object), you'll see how things align (or don't). Now, if an object does not render properly in pd-l2ork because of this translation, then what is needed is simply nudging it in the opposite direction. However, if the object appears within the GOP boundaries but is still not visible in GOP window, then there may be some stale things I missed in the getrect call for hsl. In this case, please do file a bug report. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] l2ork: SSSAD loads but doesn't save presets
On 06/24/2013 07:06 AM, András Murányi wrote: Yes this is with l2ork and it works in Vanilla (haven't tested in Extended as it's not set up yet). The problem started a few weeks ago and I cannot recall what change I may have made to the system, because it took me some time to notice the problem. It can easily be a symptom specific to my setup, the weird thing is that there are no console errors, and that the whole setup has been reset (except for the pd-externals folder, but SSSAD itself was reset too). I'll look into preset_hub and co but right now I wish to make music instead of rewriting patches... but of course this is the life of a pd'er. :o) So, any hint how to track this down would be highly appreciated. András On Sun, Jun 23, 2013 at 11:57 PM, Ivica Bukvic i...@vt.edu mailto:i...@vt.edu wrote: Is this in pd-l2ork? Up until recently in L2Ork we relied upon sssad exclusively for our preset needs, so I am fairly sure it works fine over here. I haven't tested it with latest version of pd-l2ork yet, though. That said, if you are using pd-l2ork why not use preset_hub and preset_node instead? It does everything sssad does and way more, like saving presets with the patch as well as ability to use multiple instances of the same abstraction and have its member nodes differentiated from each other. HTH On Jun 23, 2013 3:52 PM, András Murányi muran...@gmail.com mailto:muran...@gmail.com wrote: Dear List, I've been having a problem with SSSAD for a few weeks: it's able to load presets, but when it comes to saving, an empty state is written (i mean, it does write but it overwrites the previous content of the preset with nothingness). The example patches don't work either. There are no errors in the console and I have also overwritten the whole SSSAD folder with a newly downloaded one, still no joy. Tested in vanilla and it works. András ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list BTW, I just tested sssad in latest version of pd-l2ork and it works fine over here. If you can send me offending pataches you're using and that work on vanilla but not on pd-l2ork I may be able to troubleshoot further. HTH -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] l2ork externals install
On 06/20/2013 08:25 PM, Ivica Ico Bukvic wrote: On 06/20/2013 08:20 PM, András Murányi wrote: I used tar_em_up.sh -F (then untar and make install) which produced the following in /usr/local/lib/pd-l2ork (I've removed the manually built ones from the list): adaptive expr~ parazit-help.pd array2list.pd expr~.pd_linuxparazit.pd arrayreset.pd expr.pd_linux patch_name-help.pd arraysize ext13 patch_name.pd_linux bassemu~ fexpr~.pd_linux pd~ boids fiddle~ pd-wavelet bonk~pique bsaylorGem pixeltango choice hilbert~-help.pd purepd complex-mod~-help.pd hilbert~.pd README.txt complex-mod~.pdjmmmp rev1-final.pd comportK12 rev1~-help.pd controctopus la-kitchenrev1~.pd creb rev1-stage.pd cxclist-abs rev2~-help.pd cycloneloop~ rev2~.pd disis_netreceive-help.pd lrshift~ rev3~-help.pd disis_netreceive.pd_linux Makefile.am rev3~.pd disis_netsend-help.pd makefile.subdir rradical disis_netsend.pd_linux memento rtc disis_phasor~-help.pd memento-p sfruit disis_phasor~.pd_linux sigmund~ disis_wiimote-help.pd spectdelay~-help.pd disis_wiimote.pd_linux nsend spectdelay~.pd_linux earplug~ output~-help.pd stdout ekext output~.pdtimestretch The dev libs were installed according to the l2ork web page, and none of them were unavailable. As for the build log, is there one? Or you meant the console output? Sorry, I meant console output redirect. I haven't tried -F in a while since it is pretty much all but deprecated (particularly since now pd-l2ork only conflicts with one optional pd-extended package). Perhaps there is something in -F build format that fails when -B doesn't. It is unlikely but nonetheless possible. Can you try -B (deb)? Also, please send me build log off-list with -F so that I can investigate further. Thanks! BTW, just did -F build here and it builds everything just fine. This suggests something may be off with your setup. Can you try installing whatever you've built and then trying to build from source again? If this succeeds that means that something in the build script fails to find relevant includes. Please send me your build log off-list so that I can investigate further. HTH -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] l2ork externals install
I am still in the process of cleaning up externals to make sure they are stable and robust enough to be included. This is a time-consuming process. Some of the work was already started by a colleague Stephen Carl but a lot more work remains. If you (or anyone else) would like to contribute to this process, we do have a google doc up that goes through each external and annotates what needs to be done (e.g. is it stable, does it have robust documentation, like the one Jonathan has been working on, is it a GUI object that needs additional changes to make it accelerated within pd-l2ork etc.). That said, I think iem lib should be included as far as I can tell (but may be wrong as well). extra folder does have a collection of iem* subfolders, but I am not sure which specific object is missing. If you can send me specific list of objects missing I can investigate further. HTH Best wishes, Ico On 06/20/2013 08:43 AM, András Murányi wrote: Hi All, Hi Ivica, I've reinstalled my box and I'm reinstalling l2ork and I'm having a hard time getting all the externals I need in place. Is it possible that some externals are built with ./tar_em_up.sh -F but not installed with make install? I got to admit I'm a bit confused (about which ones) because I've already built and installed moonlib and miXed manually, but now that I've arrived to iem* I see the binaries are in the build folder but not in /usr/lib/pd-l2ork/extra. I'd appreciate some guidance... Thanks! András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] l2ork externals install
On 06/20/2013 11:35 AM, András Murányi wrote: On Thu, Jun 20, 2013 at 3:56 PM, Ivica Ico Bukvic i...@vt.edu mailto:i...@vt.edu wrote: I am still in the process of cleaning up externals to make sure they are stable and robust enough to be included. This is a time-consuming process. Some of the work was already started by a colleague Stephen Carl but a lot more work remains. If you (or anyone else) would like to contribute to this process, we do have a google doc up that goes through each external and annotates what needs to be done (e.g. is it stable, does it have robust documentation, like the one Jonathan has been working on, is it a GUI object that needs additional changes to make it accelerated within pd-l2ork etc.). That said, I think iem lib should be included as far as I can tell (but may be wrong as well). extra folder does have a collection of iem* subfolders, but I am not sure which specific object is missing. If you can send me specific list of objects missing I can investigate further. Well, not a definite list, but: - moonlib and flatspace: are in the sources, not compiled by default, but added to LIB_TARGETS in externals/Makefile can be compiled, installed and they do work, Those have been disabled in pd-l2ork as they have way too many problems or are redundant. Please correct me if I am missing something. - loaders(/libdir): in the sources, not compiled by default, I compiled and installed it manually, and it works, I have that one just fine. - miXed(/toxy): in the sources, not compiled by default, I compiled it manually and installed it even more manually (ie make install doesn't work), and I only tested 'widget', which party works. I need it badly though, and 'widget popop', which I use, happens to work. Definitely needs some massaging to be included. Ditto for these just like flatspace and moonlib. - iem*: are in the sources, seem to be not compiled by default - and this is where I chose to write to the list so cannot yet tell about compile/install. What about all the iem* folders inside the extra/ folder? What objects exactly are missing? I have: iem16 iem_adaptfilt iem_ambi iem_bin_ambi iem_delay iemgui iemguts iemlib iemmatrix iem_roomsim iem_spec2 iem_tab iemxmlrpc Are you by any chance running a self-built deb? If so, have you made sure to install all the dev libs? Seems to me if you've built your own binaries that you may have not successfully built all the libs and that something has silently failed. Checking the build log may shed some light as to what is going on. András On 06/20/2013 08:43 AM, András Murányi wrote: Hi All, Hi Ivica, I've reinstalled my box and I'm reinstalling l2ork and I'm having a hard time getting all the externals I need in place. Is it possible that some externals are built with ./tar_em_up.sh -F but not installed with make install? I got to admit I'm a bit confused (about which ones) because I've already built and installed moonlib and miXed manually, but now that I've arrived to iem* I see the binaries are in the build folder but not in /usr/lib/pd-l2ork/extra. I'd appreciate some guidance... Thanks! András ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] l2ork externals install
On 06/20/2013 08:20 PM, András Murányi wrote: I used tar_em_up.sh -F (then untar and make install) which produced the following in /usr/local/lib/pd-l2ork (I've removed the manually built ones from the list): adaptive expr~ parazit-help.pd array2list.pd expr~.pd_linuxparazit.pd arrayreset.pd expr.pd_linux patch_name-help.pd arraysize ext13 patch_name.pd_linux bassemu~ fexpr~.pd_linux pd~ boids fiddle~ pd-wavelet bonk~pique bsaylorGem pixeltango choice hilbert~-help.pd purepd complex-mod~-help.pd hilbert~.pd README.txt complex-mod~.pdjmmmp rev1-final.pd comportK12 rev1~-help.pd controctopus la-kitchenrev1~.pd creb rev1-stage.pd cxclist-abs rev2~-help.pd cycloneloop~ rev2~.pd disis_netreceive-help.pd lrshift~ rev3~-help.pd disis_netreceive.pd_linux Makefile.am rev3~.pd disis_netsend-help.pd makefile.subdir rradical disis_netsend.pd_linux memento rtc disis_phasor~-help.pd memento-p sfruit disis_phasor~.pd_linux sigmund~ disis_wiimote-help.pd spectdelay~-help.pd disis_wiimote.pd_linux nsend spectdelay~.pd_linux earplug~ output~-help.pd stdout ekext output~.pdtimestretch The dev libs were installed according to the l2ork web page, and none of them were unavailable. As for the build log, is there one? Or you meant the console output? Sorry, I meant console output redirect. I haven't tried -F in a while since it is pretty much all but deprecated (particularly since now pd-l2ork only conflicts with one optional pd-extended package). Perhaps there is something in -F build format that fails when -B doesn't. It is unlikely but nonetheless possible. Can you try -B (deb)? Also, please send me build log off-list with -F so that I can investigate further. Thanks! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: right angle connections
On 06/14/2013 01:03 AM, michael noble wrote: On Fri, Jun 14, 2013 at 1:45 AM, Jonathan Wilkes jancs...@yahoo.com mailto:jancs...@yahoo.com wrote: They improve readability in situations where a straightforward, structured patch ends up with a line crossing over and obscuring text. I'll go out on a limb as someone who rarely posts here. I've been working on a single complex patch, with many abstractions and sub-patches, for a long time now and one of the greatest pleasures of patching in PD for me is taking the time to avoid visual clutter within the constraints of working without right-angles or bezier curves. There are basically three types of lines that look any good in PD to me - the horizontal cord, the vertical cord, and one particular diagonal in which the pixels just happen to align in a regular pattern. I would go so far as to say that working with only those three and sufficient white space one can avoid obscuring text in all situations. It takes longer because you have to think about where you place objects as well as what objects you are using, but I personally find I make better patching decisions based solely on the fact that I am forced to think longer about the patching process. So long story short, I don't agree that right-angles or beziers are a requirement for clear, structured and readable patches. They may be helpful time-saving tools, but using them would come at a cost for me. While I agree with you that in most cases segmented patch cords are unnecessary, if you never have a need for them I presume you must be then using sends and receives for any situation where there is a feedback loop like: [object] x [object] Segmented patch cords have their advantages, but like any tool, they can be also misused to produce even less readable patches. Time permitting and provided there is enough interest I may look into adding segmented patch cords into pd-l2ork. Cheers! -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: right angle connections
On 06/14/2013 12:07 PM, Jonathan Wilkes wrote: The real problem is: having the feature forces every pd flavor to understand them at the file format level, even if not rendering it. If the connect method took A_GIMME you could just follow its initial four floats with a list of coordinates. -Jonathan Indeed. This is how pd-l2ork maintains backwards compatibility for a number of features. That said, storing coordinates in the existing file format and/or drawing the cord are not the problem. The problem is what happens when you translate the object the cord is connected to? Uncovering logic whether all the coordinates need to be translated (as opposed to only last one) is something that even Max fails to do gracefully despite the fact it has been capable of this for over 10 years, perhaps in part because there is no perfect/graceful way to deal with this that does not require some fairly evolved logic. Another challenge is cord selection. What needs to be checked is if the existing cord selection logic is indeed robust to handle new segmented cords. Although my memory is not what it used to be, as far as I remember, the hitbox detection is fairly primitive when it comes to cords and in its current form is not capable of gracefully handling this. Please correct me if I am wrong. Perhaps more pressing matter IMO is ability to multiselect cords so that you can erase many of them at once without having to resort to hack-ish ways of cutting and pasting objects. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: New Pd-L2Ork x86_64 and Raspberry Pi release now available together with comprehensive how-to
Do you have dpkg-deb program installed? What happens when you type dpkg-deb in command line? Also, can you resend the attachment off-list as there was nothing attached (AFAICT). Thanks! -Original Message- From: ro...@dds.nl [mailto:ro...@dds.nl] Sent: Monday, June 10, 2013 5:47 PM To: Ivica Ico Bukvic Cc: 'pd-list' Subject: Re: [PD] ANN: New Pd-L2Ork x86_64 and Raspberry Pi release now available together with comprehensive how-to Ivica Ico Bukvic i...@vt.edu schreef: no, it didn't (yet?) first there was the message that some dpkg data was locked. trying to resolve that, there was found a strange new update file, filled with #padding lines. up until now i did not succeed to 'repair' the dpkg process i'll inform you lateron rolf That looks like something on your dpkg setup is messed up. You may want to google for a resolution. Best wishes, Ico hi ico, i made a fresh install of Ubuntu 12.04 repeated all the steps described by you / at the l2ork site. i used this command to save the output: ./tar_em_up.sh -B | tee l2ork-out.txt according to this file (attached) there should be a deb. in the terminal window however the text at the end is: [...] fakeroot dpkg-deb --build /home/rolf/pd-l2ork/packages/linux_make/build/ /home/rolf/pd-l2ork/packages/linux_make/pd-l2ork-`arch`-20130610.deb getopt: onbekende optie '--build' fakeroot, create a fake root environment. usage: fakeroot [-l|--lib fakerootlib] [-f|--faked fakedbin] [-i file] [-s file] [-u|--unknown-is-real] [-b|--fd-base fd] [-h|--help] [-v|--version] [--] [command] make: *** [deb] Fout 1 move full installer... mv: kan status van ‘*.deb’ niet opvragen: Bestand of map bestaat niet done. [...] apparently the error messages are not included in the file. there is no deb. rolf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: New Pd-L2Ork x86_64 and Raspberry Pi release now available together with comprehensive how-to
on the git page there's a possibility to download the zip anyway, after cleaning i did (again) git clone.etc attached the output of ./tar_em_up.sh -B thanks, rolf Looking at the log, it looks like you had a successful build. Did you try to install the newly created deb as per instructions found on the pd-l2ork software page? Namely: cd /home/rolf sudo dpkg -i pd-l2ork*0607.deb Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI preferences frame
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Jonathan Wilkes Sent: Friday, June 07, 2013 5:03 PM To: 'pd-list' Subject: [PD] GUI preferences frame Hello list, I've now got the audio dialog and midi dialog of the new Pd Preferences menu working. Now it's time for the GUI dialog. Some questions: 1. Are there hooks for saving gui preferences to the Pd settings file? I don't see anything in Vanilla. Has pd-l2ork implemented those hooks? Pd-l2ork's hooks are currently only accessible via sys_vgui since they reside in tk-land. Making this canvas-side should not be too difficult but will require some additional work. 2. What options should be available in the GUI dialog? 3. How should it update? Immediately after the user makes a choice? 4. How should these settings interact with settings from within the patch? The only workable solution I see is that things should just work as they work, probably meaning that patchlevel options (which are presumably loadbanged into being) would supersede the GUI dialog settings. And I can put a Refresh or Apply button in the dialog so the user can manually override. Here's a start for the options: 1) canvas bg color 2) font color/size/face This will require a lot more than this since pd has two ways of dealing with fonts-one for iemguis and other for everything else. This needs to be streamlined before anything can be done with this option. 3) text selection color 4) wire color 5) box outline color 6) box fill color 4-6 should by object- rather than canvas-specific 7) xlet color 8) active xlet color 9) link color (for pddplink/helplink) IMO this should be pddplink-specific rather than canvas-specific And also 0) Dropdown list of presets for whatever people might want quick access to like: Ubuntu x.x, Linux Mint, high contrast, inverted from default (black bg with white text). (At least I don't know a way to get tk to inherit GNU/Linux themes so this would be a workaround for that.) This is currently impossible to handle due to Tk's limited ability to interface with the rest of the desktop in terms of themes. As such I would leave it out for the time being. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: New Pd-L2Ork x86_64 and Raspberry Pi release now available together with comprehensive how-to
on the git page there's a possibility to download the zip anyway, after cleaning i did (again) git clone.etc attached the output of ./tar_em_up.sh -B thanks, rolf Looking at the log, it looks like you had a successful build. Did you try to install the newly created deb as per instructions found on the pd-l2ork software page? Namely: cd /home/rolf sudo dpkg -i pd-l2ork*0607.deb Ico Just checking, did the above work? ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] ANN: New Pd-L2Ork x86_64 and Raspberry Pi release now available together with comprehensive how-to
Looks like you don't have git installed which is unusual, as that is what you need to get the source from git in the first place. Do: sudo apt-get install git Then use git to retrieve latest source (as per pd-l2ork documentation found at http://l2ork.music.vt.edu/main/?page_id=56#install-dev): git clone git://github.com/pd-l2ork/pd.git pd-l2ork Then inside the newly created pd-l2ork/ folder go to l2ork_addons folder and follow instructions below. HTH -Original Message- From: ro...@dds.nl [mailto:ro...@dds.nl] Sent: Wednesday, June 05, 2013 10:31 PM To: Ivica Bukvic Cc: pd-list Subject: Re: [PD] ANN: New Pd-L2Ork x86_64 and Raspberry Pi release now available together with comprehensive how-to Ivica Bukvic i...@vt.edu schreef: Forgot to mention, building your own is a simple three-step process: 1) get the source from git 2) run the apt-get command found on L2Ork's software page to install Dev libraries (simply copy and paste it into terminal) 3) in the source tree cd into l2ork_addons/ folder and run: ./tar_em_up.sh -B Go get a lunch/coffee, come back in an hour and install your own brand new pd-l2ork (it will be located two folders up so you will have to type cd ../../ to get there) HTH hi ivica, following your guidelines i get some errors and no result. my system is in dutch, but i think the errors are clear. in the beginning there is this: [..] ./tar_em_up.sh: regel 125: git: opdracht niet gevonden ./tar_em_up.sh: regel 126: git: opdracht niet gevonden [..] the lines in question are: git submodule init git submodule update lateron the proces ends with these lines: [...] make[1]: *** Er is geen regel om doel '/home/rolfm/Downloads/pd-master/Gem/configure' te maken, nodig voor '/home/rolfm/Downloads/pd-master/Gem/src/.libs/Gem.pd_linux'. Gestopt. make[1]: Map '/home/rolfm/Downloads/pd-master/packages' wordt verlaten make: *** [install] Fout 2 fakeroot dpkg-deb --build /home/rolfm/Downloads/pd-master/packages/linux_make/build/ /home/rolfm/Downloads/pd-master/packages/linux_make/pd-l2ork-`arch`- 20130605.deb getopt: onbekende optie '--build' unknown option fakeroot, create a fake root environment. usage: fakeroot [-l|--lib fakerootlib] [-f|--faked fakedbin] [-i file] [-s file] [-u|--unknown-is-real] [-b|--fd-base fd] [-h|--help] [-v|--version] [--] [command] make: *** [deb] Fout 1 move full installer... mv: kan status van ?*.deb? niet opvragen: Bestand of map bestaat niet [...] any suggestions? i am on Ubuntu 12.04 rolf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Sensors GPIO Raspberry Pi Pd
Thank you very much! From: Julian Brooks [mailto:jbee...@gmail.com] Sent: Monday, June 03, 2013 6:11 AM To: Ivica Bukvic Cc: pd-list; Martin Peach; George Naylor Subject: Re: [PD] Sensors GPIO Raspberry Pi Pd Hey Ivica, All the info is on this thread: http://www.mail-archive.com/pd-list@iem.at/msg57752.html The object is [gpio] and whilst working fine, is pretty basic. Jaime's helpfile is very useful and recommended. OAN - Had a quick look at your site for the RPI version of pd-l2ork - really excellent documentation, looks great, hats off to you. Should have more time next month to properly engage with pd-l2ork - looking forward to it. Cheers, Julian On 3 June 2013 05:42, Ivica Bukvic i...@vt.edu wrote: Joining late to the discussion--is there now a native Pd external that allows direct connection to RPi pins or is there still a need to use middleware to access the data steam? If former, where can one get their hands on the source--I would love to include it in the next pd-l2ork RPi release? Please advise. On May 23, 2013 8:20 AM, Julian Brooks jbee...@gmail.com wrote: Just checked it again and noticeably in comparison to all our previous testing there is now (as good as) zero errors from the sensors. Rock solid. Joy. On 23 May 2013 13:16, Julian Brooks jbee...@gmail.com wrote: Hey Martin, Many thanks for the extra wiring diagram. We managed to confirm both sensors are working via pin11 from the IC going between earth 3v with gpio17 disconnected and running i2cdetect. That was really useful as it was the first definite confirmation that both sensors are working correctly. In the process of doing that we also discovered that the line from gpio17 to IC pin11 was in fact not connected to gpio17 at all! To try and keep the protoplate reasonably tidy we'd soldered to the underneath of the plate. Somehow in the flipping from one side to the other we'd messed up and missed by two connecting it to ground and therefore making complete sense as to why only one sensor was working. This is also after spending a half hour this morning checking and double checking all the various lines and connections. So working now - blimey. OAN - Whilst wanting to progress the Pd patch last night, having left it since last Friday, I plugged the box with all our gubbins in and promptly blew up the Pi - proper fried it it seems. Loose power cable to the Pi and we think it was touching a screw on the box. Kapput. The RPi was a rev1 board and my other is rev2 and the custom image I made doesn't work on the rev2 board. Always know this was a possible issue but, you know, got a ton of other stuff to be getting on with. So spent until 4am building a fresh image from http://moebiuslinux.sourceforge.net/ and works really well so far-which is good. Didn't get my patching done though:) Long way of saying that I've updated my C file to reflect this and all working lovely. Thank you thank you thank you. Been much fun, Julian P.S. Will give this thread a nudge when I've documented it all (it's a whopper) ___ 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] ANN: New Pd-L2Ork x86_64 and Raspberry Pi release now available together with comprehensive how-to
duplicating an object *proper fix for the crash when closing one of the many concurrently open root patches *automated installer clean-up for flext *remaining clean-up and flext integration in the intel/rpi build process *dependencies update *updated postlude *improved shortcuts so that pd-l2ork auto-creates midi ports on start-up *support for flext and auto-building of fluid~ and disis_munger~ *fixed bug where select all did not work with Console window focused *fixed regression where windows were not properly raised *improved window placement logic of new pd windows *improvements to disis_wiimote to provide unsuccessful attempt at connecting with an explicit 0 from the connect outlet (version bump to 1.0.4) *fixed stray bugs that were introduced with drawsymbol and resizable fonts and made drawnumber font resizable as well *made drawsymbol a distinct object that properly opens its help file and also supports resizable fonts *added input highlighting ability like that of iemgui's number2 to gatom class *fixed text not getting displaced properly while dragging a scalar (due to incomplete accelerated displace implementation) *fixed segfault due to delayed freeing of bindlists (necessary to prevent a segfault for dynamically changed sends/receives) *improvements to the incremental install script *new/improved icons *fixed typo for the new -r option (RPi build) *Improvements to the disconnection logic to the disis_wiimote *made shortcuts more flexible in terms of startup (not forcing JACK, which will help on setups that don't want/need JACK backend), as well as providing intelligent menu shortcuts for ALSA and JACK *made disis_wiimote statically linked so that new installs do not require install of the custom cwiid library that potentially clashes with other deb-based versions. *fixed regression from IOhannes' proposed fix (see e7acc4796b655100b650f898bb10687fb9f7355d commit) that affects propagation of scalar pointers through the trigger object. Use scalar-help.pd to test. *hopefully improved libglew support due to unfortunately named libs that limit their flexible rollout across different versions of Ubuntu (and likely other distros as well) *hopefully fixed stray iemgui dialog error when returning from the custom color selection dialog *removed unnecessary canvas_vis consistency check *fixed erroneous undo behavior after cutting two objects in a row *updated moonlib to the latest version and made changes to mknob.c to support accelerated displacing with tag *fixed midi dialogs *added ability for select object to recognize bang events *improved IO Error button on/off handling *refinements to the memory leak fix that avoid tripping consistency check in the findrtext *further refined trigger mechanism to offer ability to convert anything-symbol *implemented improvement for empty lists as suggested by IOhannes http://lists.puredata.info/pipermail/pd-list/2013-02/101518.html *fixed remaining memory leaks when instantiating/deleting abstractions (see previous commit). *minor adjustments to the binary script-based installer for the pd~ external support. *fixed bug where pd-l2ork symlink for pd~ external did not get installed Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork multiconnect
Many thanks for making these, Jonathan. A couple things that may streamline your future tutorial videos is to use Pd-L2Ork version of tidy: 1) create an object (e.g. a number) 2) duplicate n times 3) select all created number objects 4) press ctrl+y to line them up all horizontally (pd-l2ork picks the closest axis with horizontal being preferred when distance between both is the same) 5) press ctrl+y once again to space them evenly so that they don't overlap tl;dr version: press ctrl+y twice Another thing to point out is when you try to connect one object's outlets to multiple objects or multiple objects into one object's inlets, pd-l2ork picks the best option that yields most valid connections. Finally, when patching two objects with many nlets (e.g. unpack n - pack n), pd-l2ork will patch as many connections as possible. So, if you select 3rd outlet (out of let's say 5), and the 1st inlet on a 5 inlet receiving object, pd-l2ork will create 3 valid connections (3-1, 4-2, and 5-3). HTH Best wishes, Ico On 05/28/2013 12:18 PM, Jonathan Wilkes wrote: Plus there are some other behaviors which I didn't cover here: https://github.com/pd-l2ork/pd/commit/7f3006a63c8b5d437958d1635528033ea951f6ea -Jonathan *From:* Jonathan Wilkes jancs...@yahoo.com *To:* pd-list@iem.at pd-list@iem.at *Sent:* Tuesday, May 28, 2013 12:17 PM *Subject:* pd-l2ork multiconnect Here are some videos of the multiconnect feature set Ivica added to Pd-l2ork: 1. One object's outlets to many objects' inlets: http://puredata.info/Members/jancsika/mc1.webm/view * all objects are selected to get this functionality 2. Many objects' outlets to one object's inlet: http://puredata.info/Members/jancsika/mc2.webm/view * objects to connect _from_ are selected, object to connect _to_ are deselected to get this functionality 3. One object's leftmost inlet to many objects: http://puredata.info/Members/jancsika/mc3.webm/view * objects to connect _to_ are selected, object to connect _from_ is deselected to get this functionality -Jonathan ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] first exercise with data structures
On 05/26/2013 10:14 PM, Ivica Ico Bukvic wrote: * cannot easily set hotspot for mouse manipulation * hotspot bug http://sourceforge.net/tracker/index.php?func=detailaid=2457992group_id=55736atid=478070 Confirmed in pd-l2ork. Will look into this next... This has been fixed in the latest pd-l2ork git as well as nested arrays now have properly aligned selection hotspot/selection box (latter may require further testing for regressions). For more info on the bugfix (it's a bit messy as I had to spend some time learning how this part of the code works) see: https://github.com/pd-l2ork/pd/commit/f0916f85a11894a43067d5b07ae5f8eea2b2c1b9 Regarding sluggish scalars/structs, pd-l2ork already accelerates their displacement when editing and moving entire scalars around. I am still working on figuring out how to deal with struct selection and displacement at runtime. * flickering animation with arrays and/or lots of scalars on screen This is most likely due to scalars currently redrawing themselves every time you move something which becomes increasingly obvious when you have lots of stuff on screen. * crashes with nested arrays when changing struct args I've been experimenting with the patch provided in the bug report that has nested structs and no matter what I delete/change, I've not yet managed to crash pd-l2ork. If you find a way to do this, an example patch will be most appreciated. Cheers! P.S. Next pd-l2ork release is imminent with some really cool new features, like intelligent multi-connect and more accelerated operations (pddplink), as well as the usual bagful of bugfixes. -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Dspstate~ in puredata
Pd-l2ork -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of João Pais Sent: Wednesday, May 01, 2013 5:26 AM To: Alexandre Torres Porres; IOhannes zmölnig; Jonathan Wilkes Cc: pd-list@iem.at Subject: Re: [PD] Dspstate~ in puredata accessible from within a pd patch (or designed to be). I made [pdinfo] so that the user can actually query all these attributes in a simple way using a single object. where is [pdinfo] to be found? ___ 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] Resize GUI objects in GOP ?
Not sure if you are referring to iemgui objects. If so, check out pd-l2ork which has bevels that allow easy resizing of gui objects and repositioning of its labels, including resizing and moving the gop area itself. The latest version (to be uploaded shortly) also has a comprehensive checking for all labels and comments to see if they fit the gop window, including dynamic changes to their properties. Pd-L2Ork also auto-adjusts fonts in objects like numbox2 when they are resized so that you don't have to guess the font size that best fits that specific size. HTH On 04/29/2013 11:40 AM, Abel Jérôme wrote: Hi, To make patches for friends or to show them to newbies, I need present things very clearly, and bigger. So I need to increase sizes of the font and GUIS. The standard font properties (Ctl+T) is quite nice, but boxes are sometimes stack on others. The main issue is to resize GUI objects placed in abstractions. I saw the [universal] object which could be use to resize GUIS. Use it with the [donecanviasdialog message, it could be okay. But is there someone who think about a simplier solution, with the iemguts lib for instance ? Thanks, -- Jerome http://jeromeabel.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Negative input numbers for [pow] return 0
It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See: https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70 -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-23 11:50, Joe White wrote: Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -END PGP SIGNATURE- ___ 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] FW: Negative input numbers for [pow] return 0
Forgot to copy list. From: Ivica Ico Bukvic [mailto:i...@vt.edu] Sent: Tuesday, April 23, 2013 11:15 PM To: 'Charles Z Henry' Subject: RE: [PD] Negative input numbers for [pow] return 0 Yes, the proposed patch generates 0 when imaginary numbers are involved and issues warning on the console with ability to track the error. From: Charles Z Henry [mailto:czhe...@gmail.com] Sent: Tuesday, April 23, 2013 10:39 PM To: Ivica Ico Bukvic Cc: pd-list; IOhannes m zmoelnig Subject: Re: [PD] Negative input numbers for [pow] return 0 Yep. It's damaging to have NaN's propagating around in Pd. [pow] having a single output means that you only want real values. The result is not a real number-I think the result should just be set to 0 (perhaps 1 depending on what the worst usage case is). Would it be better to have pow just output the real part of the complex number, generated from: (-1*base)^exp*e^(pi*exp*i) Which is (-1*base)^exp*cos(pi*exp) when base is a negative number this assumes the standard branch cut in complex analysis: -1=e^(pi*i) and not e^(3*pi*i) or any other Chuck On Apr 23, 2013 9:11 PM, Ivica Ico Bukvic i...@vt.edu wrote: It may be a bit more complex since exponent values between -1 and 1 are the ones that generate imaginary numbers from negative values, with the exception of 0 which generates 1. Latest pd-l2ork patch tries to fix this. See: https://github.com/pd-l2ork/pd/commit/95d82d33d2580a00e32d725e0f5147d88cdaf3 70 -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Tuesday, April 23, 2013 6:21 AM To: pd-list@iem.at Subject: Re: [PD] Negative input numbers for [pow] return 0 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-23 11:50, Joe White wrote: Out of curiosity, are the workarounds suggested more of a result of the difficulty of extending the Pd core rather than the implications that such a change might have? the implementation would be trivial (merely removing the safeguards that currently clamp the value to 0) fgmasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlF2YIEACgkQkX2Xpv6ydvQyoQCgiC95SRoOKaOHu6qkmpX+kD8 0 /ugAoJymAbmtt6qWkZM5rAlObyhdarRF =KUIu -END PGP SIGNATURE- ___ 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] Drawing a sine function dynamically in Gem
You may want to investigate latest version of pd-l2ork that also includes ability to assign different font sizes to drawnumber and drawsymbol (optional last argument, can be assigned to a variable but currently only supports pd-defined font sizes). It also separates the two into two distinct externals so that when you do the help on drawsymbol you don't end-up with drawnumber help file. I don't have a help file amended yet. It would be great if this ended up in the core documentation project. -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Jonathan Wilkes Sent: Thursday, April 04, 2013 5:36 PM To: Orm Finnendahl; pd-list@iem.at Subject: Re: [PD] Drawing a sine function dynamically in Gem Btw-- I just uploaded a patch that adds [drawoval], [filledoval], [drawrectangle], and [filledrectangle] to data structure drawing instructions. This way you can just specify a pair of bounding box coords and let tk draw the circle, rather than simulating one with a polygon with lots of sides. :) -Jonathan - Original Message - From: Orm Finnendahl o.finnend...@inm.mh-freiburg.de To: pd-list@iem.at Cc: Sent: Wednesday, April 3, 2013 12:01 PM Subject: Re: [PD] Drawing a sine function dynamically in Gem Hi Alexandros, attached is an example to do this with vanilla pd using datastructs instead of GEM. You'll have to save both files (sine-wave-sub.pd and sine-wave.pd) under these names in the same folder and open up sine-wave.pd. The animation should start right away... Is that what you were looking for? -- Orm ___ 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
[PD] State of dssi/plugin support on Linux (Ubuntu 12.04)
All, I did some digging around existing plugin solutions for fluidsynth and other synths on Linux and so far had no luck. pluginhost~ segfaults as soon as it is loaded (help patch does). Removing :hexter from the [pluginhost~ hexter.so:hexter 2] fixes this but one cannot open any of the guis (they all either do not do anything or eventually crash pd. The old fluid~ is gone, nowhere to be found, so is dssi~. It is possible that this problem stems from some weird configuration on my system but before I try digging in that direction, just wanted to see what everyone else's thoughts were on this one. The problem btw manifests both on local build of pd-extended and pd-l2ork. Not sure about vanilla... -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] State of dssi/plugin support on Linux (Ubuntu 12.04)
On 04/07/2013 12:08 AM, Ivica Ico Bukvic wrote: All, I did some digging around existing plugin solutions for fluidsynth and other synths on Linux and so far had no luck. pluginhost~ segfaults as soon as it is loaded (help patch does). Removing :hexter from the [pluginhost~ hexter.so:hexter 2] fixes this but one cannot open any of the guis (they all either do not do anything or eventually crash pd. The old fluid~ is gone, nowhere to be found, so is dssi~. It is possible that this problem stems from some weird configuration on my system but before I try digging in that direction, just wanted to see what everyone else's thoughts were on this one. The problem btw manifests both on local build of pd-extended and pd-l2ork. Not sure about vanilla... To add to this, jack-dssi-host fluidsynth-dssi.so works perfectly fine. In pd/pd-l2ork when creating [pluginhost~ fluidsynth-dssi.so] works (creates 3 outlets and reports no errors) but trying to open the gui does nothing. I do get a warning about DSSI path not set, but its defaults are correct (and the external finds the .so file fine). Trying something like [pluginhost~ calf.so:Reverb] (or reverb) or any other legitimate combo that uses :plugin crashes pd immediately. Has anyone else had any luck with it or has any alternatives? -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] subnormal numbers explained
If freeverb~ is compiled properly and you are not running it on a platform whose processor does not gracefully handle denormals, you should not have to do anything. -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of João Pais Sent: Wednesday, April 03, 2013 1:36 PM To: katja; James Dunn Cc: pd-list Subject: Re: [PD] subnormal numbers explained I add some very very very low noise to the audio signal, it really doesn't affect the audio. something like [noise~] | [lop~ 5] | [*~ 0.0001] it's dirty, but it works (?). Do you have any arguments against it? João Quoth katja, on 13/03/2013 10:14: Subnormal numbers are a pain in the ass, they cause substantially increased CPU load without doing anything useful for audio DSP. Unfortunately it can happen in some Pd objects (notably [freeverb~]), and spoil the performance of a Pd patch. Yes I eventually found this out and started putting [freeverb~] in a subpatch with a [env~] connected to [sel 0] and then to a [switch~] object to turn off dsp when the reverb tail has finished. The logic ended up getting quite complicated but it did the job! James ___ 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] bang vs empty list
IOhannes,
Your patch has one regression:
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol *s, int
argc, t_atom *argv)
else if (u-u_type == TR_SYMBOL)
outlet_symbol(u-u_outlet,
(argc ? atom_getsymbol(argv) : s_symbol));
+else if (u-u_type == TR_ANYTHING)
+outlet_anything(u-u_outlet, s, argc, argv);
else if (u-u_type == TR_POINTER)
{
if (!argc || argv-a_type != TR_POINTER)
This part causes pointers to not properly propagate through the trigger
objects. If you run scalar-help.pd file (part of pd-extended/pd-l2ork
documentation developed by Jonathan and others), clicking on scalars that
should animate generates an error. Removing this works fine for scalars but I
wonder if it then disables functionality of the patch you provided.
Any thoughts?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
On 03/21/2013 03:12 PM, Ivica Ico Bukvic wrote:
IOhannes,
Your patch has one regression:
--- a/src/x_connective.c
+++ b/src/x_connective.c
@@ -991,6 +991,8 @@ static void trigger_list(t_trigger *x, t_symbol
*s, int argc, t_atom *argv)
else if (u-u_type == TR_SYMBOL)
outlet_symbol(u-u_outlet,
(argc ? atom_getsymbol(argv) : s_symbol));
+else if (u-u_type == TR_ANYTHING)
+outlet_anything(u-u_outlet, s, argc, argv);
else if (u-u_type == TR_POINTER)
{
if (!argc || argv-a_type != TR_POINTER)
This part causes pointers to not properly propagate through the
trigger objects. If you run scalar-help.pd file (part of
pd-extended/pd-l2ork documentation developed by Jonathan and others),
clicking on scalars that should animate generates an error. Removing
this works fine for scalars but I wonder if it then disables
functionality of the patch you provided.
Any thoughts?
As of right now, I cannot see any regressions by removing that part
since at the end it does output_list call anyhow. Can you test this/confirm?
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Large File Support on Linux
Miller, Does this mean if one were not so concerned with backwards compatibility and included define you listed below in the s_path.c that this would fix the LFS issue albeit at the expense of backwards/cross-platform compatibility? Also, in Linux is open64 safe for both 32-bit and 64-bit OS variants? -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Miller Puckette Sent: Wednesday, March 20, 2013 6:46 PM To: IOhannes m zmölnig Cc: pd-list@iem.at Subject: Re: [PD] Large File Support on Linux OK.. I think I'm sold (for 0.45 :) on trying to get sys_open, etc., to do the right thing. I guess on Windows this would have to be somehow both UTF8 and 64-bit safe - all the more reason to do as you suggest and hide the whole mes behind sys_this_and_that() variants. I thought exactly the same thing about a find_via_path routine. It seems to me that open_via_path, which tries not just to verify that the file exists but also that it can actually be opened, is perhaps working too hard; if a file that proves impossible to open is in an earlier spot on the path, the best thing might be to try and fail to open it instead of going out to another, perhaps incorrect, version of the file. Also, it could be fixed to take the path as an argument so that d_soundfile.c can call it from other threads safely (using separate copies of the path). cheers Miller On Wed, Mar 20, 2013 at 09:42:42PM +0100, IOhannes m zmölnig wrote: On 03/20/2013 18:02, Miller Puckette wrote: On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc. yep. that's why i said that the only real solution would be to provide a more-or-less complete set of fileIO-functions: sys_lseek, sys_stat (including f-variants). I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms. which would be possible if we provided the full set. of file accessors. (but to repeat, this is not really a Pd-problem, and could (and maybe should) be solved in an auxiliary lib). For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3). which i think is a good enough approach. but of course there's a catch: sys_open() will gracefully handle UTF-8 filenames, whereas on some platforms open() will not. so with your solution, soundfiles with non-ascii chars will fail to open on W32. since open_via_path() is so often used to determine the full path of a file somewhere in the searchpath, it might be a good idea to wrap that functionality into a find_via_path() function that returns the canonicalized filename. it would be great if that filename would be mangled in a way so UTF8 doesn't make problems any more, but i think this is simply not possible with the way w32 handles opening such filenames. fgmadsr IOhannes ___ 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] Large File Support on Linux
Could one simply redefine lseek and fstat to use lseek64 and fstat64 instead and be done with it (again, assuming one is not concerned with backwards and/or x-platform compatibility)? Best wishes, Ico -Original Message- From: Miller Puckette [mailto:m...@ucsd.edu] Sent: Wednesday, March 20, 2013 9:21 PM To: Ivica Ico Bukvic Cc: 'IOhannes m zmölnig'; pd-list@iem.at Subject: Re: [PD] Large File Support on Linux I believe not - every extern that used open_bia_path0 would have to be fixed at the source level to use lseek64(), fstat64() in place of lseek() and fstat(). I can't see any way to fix this source-compatibly. I checked open64() on 32-bit Raspbian (ARM) and it worked fine - so I think it's save to say open64 exists on all modern linuxes, both 64 and 32 bit. cheers Miller On Wed, Mar 20, 2013 at 09:14:42PM -0400, Ivica Ico Bukvic wrote: Miller, Does this mean if one were not so concerned with backwards compatibility and included define you listed below in the s_path.c that this would fix the LFS issue albeit at the expense of backwards/cross-platform compatibility? Also, in Linux is open64 safe for both 32-bit and 64-bit OS variants? -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Miller Puckette Sent: Wednesday, March 20, 2013 6:46 PM To: IOhannes m zmölnig Cc: pd-list@iem.at Subject: Re: [PD] Large File Support on Linux OK.. I think I'm sold (for 0.45 :) on trying to get sys_open, etc., to do the right thing. I guess on Windows this would have to be somehow both UTF8 and 64-bit safe - all the more reason to do as you suggest and hide the whole mes behind sys_this_and_that() variants. I thought exactly the same thing about a find_via_path routine. It seems to me that open_via_path, which tries not just to verify that the file exists but also that it can actually be opened, is perhaps working too hard; if a file that proves impossible to open is in an earlier spot on the path, the best thing might be to try and fail to open it instead of going out to another, perhaps incorrect, version of the file. Also, it could be fixed to take the path as an argument so that d_soundfile.c can call it from other threads safely (using separate copies of the path). cheers Miller On Wed, Mar 20, 2013 at 09:42:42PM +0100, IOhannes m zmölnig wrote: On 03/20/2013 18:02, Miller Puckette wrote: On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc. yep. that's why i said that the only real solution would be to provide a more-or-less complete set of fileIO-functions: sys_lseek, sys_stat (including f-variants). I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms. which would be possible if we provided the full set. of file accessors. (but to repeat, this is not really a Pd-problem, and could (and maybe should) be solved in an auxiliary lib). For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3). which i think is a good enough approach. but of course there's a catch: sys_open() will gracefully handle UTF-8 filenames, whereas on some platforms open() will not. so with your solution, soundfiles with non-ascii chars will fail to open on W32. since open_via_path() is so often used to determine the full path of a file somewhere in the searchpath, it might be a good idea to wrap that functionality into a find_via_path() function that returns the canonicalized filename. it would be great if that filename would be mangled in a way so UTF8 doesn't make problems any more, but i think this is simply not possible with the way w32 handles opening such filenames. fgmadsr IOhannes ___ 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] Large File Support on Linux
the problem with that is, that s_path implements an API available for externals. if open_via_path() returns a filehandle for an LFS file, and the external has been compiled without LFS, the filehande will be incompatible. see [1] for a discussion. i guess the only clean way to solve that, is to provide a complete wrapper around the file API, so an external has functions guaranteed to work with the filehandle returned by Pd. currently there are sys_open()/sys_close() and its f*-variants. but we would need at least sys_(f)seek and sys_(f)stat, but preferrably a complete wrapper around LFS-compatible file functions [2]. all this functionality (including the handilng of UTF filenames on W32) is not really Pd-related, and could well be factored out into a separate library. Thanks for the clear explanation of the matter, IOhannes. Why not simply recompile externals after fixing s_path? Pd-extended already comes with most externals recompiled for every new release and adding legacy stuff just creates more confusion in maintaining the source down the road. In other words, FWIW and IMHO I think there is way too much effort the community is trying to pour into binary compatibility for a system that clearly begs for further enhancements in the core API. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Large File Support on Linux
I completely agree with your example, Miller, as far as pd vanilla is concerned. OTOH pd-extended ships with all its externals compiled with each version, so this would be for the most part a non-issue unless: 1) users A or B are using different versions of pd (which could be elaborated upon in the documentation when sharing patches which is rather common in other software environments), or 2) if A is using custom externals that are not found in pd-extended (in which case B would not want to use those anyways unless both A and B are using the same platform, which is the only scenario where it would make sense to keep this as a workaround) Either way FWIW I still feel this is too much of a workaround for little gain and potentially a lot of headache down the road. Best wishes, Ico -Original Message- From: Miller Puckette [mailto:m...@ucsd.edu] Sent: Monday, March 18, 2013 2:47 PM To: Ivica Ico Bukvic Cc: 'IOhannes m zmoelnig'; pd-list@iem.at Subject: Re: [PD] Large File Support on Linux To answer Ico's question, the trouble I forsee is musician A gives musician B a patch, containing compiled externs - and then musician B runs it and gets a crash instead of music. Sub-optimal in my opinion :) I now think that it should be OK to use open64() only in the file d_soundfile.c and only for linux - so putting at the head of the file, #ifdef __linux__ #define _LARGEFILE64_SOURCE #endif ... then, because opening soundfiles currently uses open_via_path, simply closing the file and re-opening it via open64(). There's a similar hack to open binbufs via paths in the function binbuf_read_via_canvas(). There are two other festering problems in open_via_path() that all should probably be fixed in one go by defining an updated function call: 1. externs further down the path are chosen in front of abstractions that should be taken instead; 2. open_via_path isn't thread safe - d_soundfile.c could call it at the same moment someone in the Pd thread is changing the path. This should almost never hapen but should be fixed. This is a big enough change that I think it should wait for 0.45, whereas the hack described above could go in right now as a local bug-fix. BTW I've got a couple of other bug-fixes underway; wil push to git now. cheers Miller Oe Mon, Mar 18, 2013 at 12:47:47PM -0400, Ivica Ico Bukvic wrote: the problem with that is, that s_path implements an API available for externals. if open_via_path() returns a filehandle for an LFS file, and the external has been compiled without LFS, the filehande will be incompatible. see [1] for a discussion. i guess the only clean way to solve that, is to provide a complete wrapper around the file API, so an external has functions guaranteed to work with the filehandle returned by Pd. currently there are sys_open()/sys_close() and its f*-variants. but we would need at least sys_(f)seek and sys_(f)stat, but preferrably a complete wrapper around LFS-compatible file functions [2]. all this functionality (including the handilng of UTF filenames on W32) is not really Pd-related, and could well be factored out into a separate library. Thanks for the clear explanation of the matter, IOhannes. Why not simply recompile externals after fixing s_path? Pd-extended already comes with most externals recompiled for every new release and adding legacy stuff just creates more confusion in maintaining the source down the road. In other words, FWIW and IMHO I think there is way too much effort the community is trying to pour into binary compatibility for a system that clearly begs for further enhancements in the core API. Best wishes, Ico ___ 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] found how to reproduce Pd-ext 0.43.4 Tcl Invalid Command Name error
Just to further confirm, pd-l2ork is not affected with Benjamins example either. Hopefully this will help Hans and others hunt this thing down. Best wishes, Ico From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Hans-Christoph Steiner Sent: Thursday, March 14, 2013 11:35 PM To: ben...@free.fr Cc: Pd List Subject: Re: [PD] found how to reproduce Pd-ext 0.43.4 Tcl Invalid Command Name error That bug is not related, though I might look similar. Any time you see things like .x2415b0 those are the unique IDs that Pd uses for each Window in the GUI. .x2415b0: no such object basically means that Pd is trying to send a command to a window in the GUI, but that window does not currently exist (like it was closed) and Pd didn't get the message about that window closing. This patch is a nice clear example, so it should be possible to track the bug down. Marco, if you haven't already, can you add that patch tarball to a bug report in the tracker? A reference to this thread would also be helpful. .hc On Mar 7, 2013, at 10:25 AM, Benjamin ~ 01xy wrote: Hello, I encountered a maybe similar bug clicking on the 0 button of the Hradio in pix_video help patch : (Tcl) NOM DE COMMANDE INVALIDE : invalid command name .x8b1b038.c while executing .x8b1b038.c delete 8b26df8BASE0 (uplevel body line 14) invoked from within uplevel #0 $cmds_from_pd In Pd-extended 0.43-4 on debian 32 bit with GEM: ver: 0.93.3 compiled: Jan 28 2013 this bug disapear if I cut the wire of the left outlet of [pix_video] which goes to [s $0-info] Bugs related ? : http://sourceforge.net/tracker/index.php?func=detail http://sourceforge.net/tracker/index.php?func=detailaid=3522945group_id=5 5736atid=478070 aid=3522945group_id=55736atid=478070 ++Benjamin Le 07/03/2013 12:33, Marco Donnarumma a écrit : hey thanks all for testing. At least we know it's consistent. Let's see if somebody has ideas about it. Let me know how can I help! Really wish to solve this. thanks! -- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. Embodied Audio-Visual Interaction Research Team. Department of Computing, Goldsmiths University of London ~ Portfolio: http://marcodonnarumma.com http://marcodonnarumma.com/ Research: http://res.marcodonnarumma.com http://res.marcodonnarumma.com/ Director: http://www.liveperformersmeeting.net http://www.liveperformersmeeting.net/ On Thu, Mar 7, 2013 at 9:15 AM, batinste dwanaf...@yahoo.fr wrote: Hi Behaviour confirmed on ubuntu 12.10 64 bits and pd-ext 0.43.4. On 07/03/2013 02:02, Marco Donnarumma wrote: hey, dunno if you remember, but I still have this error (below) and now I managed to make a small patch that reproduces it (attached). It seems related to the Hide flag for a 2nd level nested GOP patch. it'd be great if somebody could test it on linux and mac. I'm on Ubuntu Lucid 10.04, pd-ext 0.43.4 how to reproduce: - launch MAIN-graph-bug.pd - click the bang to open a subpatch (if it doesn't at startup) - close the subpatch - close MAIN-graph-bug.pd at this point Pd throws the error as below. Only the GUI freezes, the patch is unusable and have to kill it, by closing pd. smb:// (Tcl) INVALID COMMAND NAME: invalid command name .x996ebd0.c while executing .x996ebd0.c delete graph996f4b0i0 (uplevel body line 1) invoked from within uplevel #0 $cmds_from_pd smb:// How to avoid it: - launch MAIN-graph-bug.pd - click the bang to open a subpatch (if it doesn't at startup) - open the subpatch - open the further subpatch anlz.scope~ - flag hide object name and argument - save -close pd - restart the patch and the error disappear It is worth noting that the error I get with the Xth Sense software looks similar but has different tags (see below). And I can't reproduce this one error using a subpatch including a graph or iem_image (which I use in the Xth Sense) smb:// (Tcl) INVALID COMMAND NAME: invalid command name .x9c4d3b0.c while executing .x9c4d3b0.c create image 900 776 -image a4304c0PHOTOIMAGE -tags a4304c0PHOTO (uplevel body line 283) invoked from within uplevel #0 $cmds_from_pd \ smb:// should i submit a different bug report or add to the one I did already? thanks in advance for any hint, this is forcing me to still use pd-ext 0.42.5 during my workshop, which is a shame :) -- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. Embodied Audio-Visual Interaction Research Team. Department of Computing, Goldsmiths University of London ~ Portfolio: http://marcodonnarumma.com http://marcodonnarumma.com/ Research: http://res.marcodonnarumma.com http://res.marcodonnarumma.com/ Director: http://www.liveperformersmeeting.net http://www.liveperformersmeeting.net/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE
Re: [PD] found how to reproduce Pd-ext 0.43.4 Tcl Invalid Command Name error
FWIW, I've done a lot of work at cleaning up gop-related bugs in pd-l2ork. This is one of them (in other words, pd-l2ork is not affected by this). It may not be a bad idea to do some code comparison between g_editor.c g_canvas.c and g_graph.c files where most of these reside in hope of merging this into regular pd/extended. On 03/06/2013 08:02 PM, Marco Donnarumma wrote: hey, dunno if you remember, but I still have this error (below) and now I managed to make a small patch that reproduces it (attached). It seems related to the Hide flag for a 2nd level nested GOP patch. it'd be great if somebody could test it on linux and mac. I'm on Ubuntu Lucid 10.04, pd-ext 0.43.4 how to reproduce: - launch MAIN-graph-bug.pd - click the bang to open a subpatch (if it doesn't at startup) - close the subpatch - close MAIN-graph-bug.pd at this point Pd throws the error as below. Only the GUI freezes, the patch is unusable and have to kill it, by closing pd. (Tcl) INVALID COMMAND NAME: invalid command name .x996ebd0.c while executing .x996ebd0.c delete graph996f4b0i0 (uplevel body line 1) invoked from within uplevel #0 $cmds_from_pd How to avoid it: - launch MAIN-graph-bug.pd - click the bang to open a subpatch (if it doesn't at startup) - open the subpatch - open the further subpatch anlz.scope~ - flag hide object name and argument - save -close pd - restart the patch and the error disappear It is worth noting that the error I get with the Xth Sense software looks similar but has different tags (see below). And I can't reproduce this one error using a subpatch including a graph or iem_image (which I use in the Xth Sense) (Tcl) INVALID COMMAND NAME: invalid command name .x9c4d3b0.c while executing .x9c4d3b0.c create image 900 776 -image a4304c0PHOTOIMAGE -tags a4304c0PHOTO (uplevel body line 283) invoked from within uplevel #0 $cmds_from_pd \ should i submit a different bug report or add to the one I did already? thanks in advance for any hint, this is forcing me to still use pd-ext 0.42.5 during my workshop, which is a shame :) -- Marco Donnarumma New Media + Sonic Arts Practitioner, Performer, Teacher, Director. Embodied Audio-Visual Interaction Research Team. Department of Computing, Goldsmiths University of London ~ Portfolio: http://marcodonnarumma.com Research: http://res.marcodonnarumma.com Director: http://www.liveperformersmeeting.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] fixes for two memory leaks
Miller, Hans, et al,
I am forwarding you two patches that are memory leaks in pd. Pd vanilla
is affected only by one of them, while pd-extended has both (second is
magicGlass that Hans ported from pd-l2ork and that I just figured out a
couple days ago). Since code bases are now fairly apart on the files
involved, I am supplying the fix in this way in hope it is easier to
understand this way.
1) The problem that affects all versions of pd can be tested using the
bug report on the sourceforge is related to rtext freeing:
http://sourceforge.net/tracker/?func=detailaid=3605235group_id=55736atid=478070
Following implementation fixes it both for GOP abstractions and
individual objects:
In g_graph.c glist_delete() call:
at the beginning of the function
+t_rtext *rt = NULL;
+int late_rtext_free = 0;
further down instad of rtext_new(x, ob);
+rt = glist_findrtext(x, ob);
+if (rt)
+late_rtext_free = 1;
at the end of the function
+if (late_rtext_free) {
+rtext_free(rt);
+}
}
}
(late_rtext_free here is to provide more clarity to the process, it is
obviously unnecessary since you could simply check for pointer value
instead)
2) Magicglass fix (affects pd-extended only, memory leak due to improper
freeing of magicGlass--to test simply check memory footprint as you keep
recreating a GOP abstraction using a variant of the patch provided on
the sourceforge):
=
in g_magicglass.c (added unbind call):
void magicGlass_free(t_magicGlass *x)
{
//fprintf(stderr,magicglass_free\n);
+magicGlass_unbind(x);
x-x_dspOn = 0;
clock_free(x-x_clearClock);
clock_free(x-x_flashClock);
}
in g_canvas.c canvas_free function:
-if (x-gl_magic_glass)
- magicGlass_free(x-gl_magic_glass);
+if (x-gl_magic_glass) {
+ //magicGlass_free(x-gl_magic_glass);
+pd_free(x-gl_magic_glass-x_obj.te_g.g_pd);
+}
=
Best wishes,
--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
OK, I checked your patch and now I know why this is happening. Allow me to explain: short (tl;dr) version: once mknob is accelerated (which should be only a couple of lines of code inside it) this won't be a problem any more For me it takes approx 3 seconds every time I move the gop window and this solely because mknob is not accelerated (this is on an HP dm1z AMD APU notebook/netbook). long version: What's happening is that pd/extended completely redraws gop object every time it is moved. What it does not do, is account for its location (front vs. back) in respect to other objects when doing this. So, for instance if you move a gop that is behind another object, once it has been moved, it will appear in front of it which is wrong since that is not an accurate reflection where in the gl_list it is located. Hence, next time your entire canvas redraws (which happens inside pd/extended at various points), suddenly gop will be again behind the other object. Confusing, no? Pd-l2ork in an attempt to keep gl_list consistent always ensures that objects remain visually stacked on top of each other in the gl_list order no matter what operation you do. In this case, because we have one of the few remaining gui objects that do not support accelerated displacement (by accelerated displacement I mean tagging such object's components in tcl tk and then moving all objects tagged with the word selected together via a single command rather than redrawing everything), pd-l2ork falls back to the old pd/extended way of doing things, just like pd/extended do. It does this with one notable exception and that is to ensure that the redrawn object remains stacked where it should be (in terms of front/back) it also redraws the canvas after such a drag because old way of redrawing does not account properly for the visual order that pd-l2ork requires. Since your patch has literally a ton of objects pertaining to ad presets, this takes a while, and hence the slowness. If you, however, put any iemgui object instead of mknob inside that gop, the thing will be not only fast, but also much faster than regular pd/extended. So, what I can do for the next release is add support for accelerated displacement of mknob and you'll be set. Another related issue is the redundant use of hundreds of ad abstractions. Pd-l2ork has system-wide preset_hub/preset_node externals system which is easy to use, supports use in conjunction with multiple instances of the same abstraction (each is treated separately and distinctly) as well as many other cool features. Think of it as pd's counterpart to Max's pattr_storage. Their implementation is currently possible only in pd-l2ork since it ensures that all objects remain in the same place in the gl_list (let's call this gl_list consistency) which is something that regular pd/extended don't do (as described above). So, long story short, if you use preset_node and preset_hub you will need only one of those to replace all of your ad abstractions. Pretty nifty? ;-) And that in near-term will make your canvas redrawing much faster and consequently a non-issue. HTH Best wishes, Ico On 03/03/2013 03:10 PM, András Murányi wrote: The original patch has many dependencies, however I've managed to put together a patch which is big enough to show the symptom but has no other dependency than mknob. Dragging the violet GOP takes quite a few seconds for me, while dragging the other GOP with the numberbox is fast. The GUI is unresponsive meanwhile. Another interesting thing is that when you select a large number of those [pd presetstore] subpatches and drag them, it really (ok not really) takes forever. But the bottleneck is not the same because the GUI stays responsive. Neither happens in pd-extended. Thanks for taking a look! András On Sun, Mar 3, 2013 at 6:47 PM, Ivica Bukvic i...@vt.edu mailto:i...@vt.edu wrote: Can you forward patch(es)? Does the abstraction use any non-default gui objects? On Mar 3, 2013 11:34 AM, András Murányi muran...@gmail.com mailto:muran...@gmail.com wrote: On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic i...@vt.edu mailto:i...@vt.edu wrote: [...] Regarding slow redraw, can you try latest version? I fixed one major inefficiency. I've just compiled the latest git and the slowness is still there. I have the vague impression though, that dragging the ominous abstraction got faster (2 minutes vs previous 5), but again, this is just an impression. András -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net
Re: [PD] check this out
EMG is potentially capable of this and with adequate filtering techniques there are papers out there that allow for fairly accurate detection of finger motions. More so, the video shows use of very distinct hand positions. In other words, it is not the gesture but hand shape that can be read accurately and interpreted. I suspect it also has a gyro/accelerometer that works in tandem with multiple EMG sensing points. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Hans-Christoph Steiner Sent: Friday, March 01, 2013 12:07 PM To: Dafydd Hughes Cc: pd list; i go bananas Subject: Re: [PD] check this out Also looks like that video was entirely faked. I see no evidence that any of that video footage was actually based on the sensor input. It probably works decently, but I highly doubt it works as well as the video. .hc On Mar 1, 2013, at 8:49 AM, Dafydd Hughes wrote: That looks like a lot of fun! On Thu, Feb 28, 2013 at 8:30 PM, i go bananas hard@gmail.com wrote: just cos there's no description, i'll add it here: it's a muscle sensor that can be used for gestural control. ___ 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] create/access udp sockets from within pd
I meant two unidirectional connections--apologies for the noise... -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of IOhannes zmölnig Sent: Friday, March 01, 2013 8:08 AM To: pd-list Subject: Re: [PD] create/access udp sockets from within pd On 03/01/2013 02:04 PM, Ivica Bukvic wrote: Sorry, missed that part. Not via a single object. Yes, when using both send and receive objects. that's interesting. or do you mean, that you can open two uni-directional UDP connections rather than one bi-directional UDP-connection? because this won't work, if the peer requests a single bi-directional communication channel, which i think this device does (and which is quite common outside Pd) fgmasdr IOhannes ___ 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] bang vs empty list
How about further expanding trigger to tolerate a-s by simply taking
the very first argument if the first argument is not type descriptor?
See attached.
e.g.
[foo
|
[t s]
|
[print]
would output foo.
foo bar-outputs foo
bar foo-outputs bar
--- x_connective.c.orig 2013-02-28 13:31:10.011297224 -0500
+++ x_connective.c 2013-02-28 13:33:08.110292915 -0500
@@ -977,6 +977,9 @@
t_triggerout *x_vec;
} t_trigger;
+// forward declaration
+static void trigger_symbol(t_trigger *x, t_symbol *s);
+
static void *trigger_new(t_symbol *s, int argc, t_atom *argv)
{
t_trigger *x = (t_trigger *)pd_new(trigger_class);
@@ -1100,8 +1103,8 @@
else if (u-u_type == TR_STATIC_SYMBOL)
{
outlet_symbol(u-u_outlet, u-u_sym);
- }
-else pd_error(x, trigger: can only convert 'a' to 'b' or 'a');
+ }
+ else trigger_symbol(x, s);
}
}
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
BTW, the only regression with this is that [select] object complains it does not understand bang. I've patched it so that when it receives a bang it redirects it to sel1_symbol and sel2_symbol with a gensym(bang). This also means that [sel b] would not work for bangs, but [sel bang] will. I think that makes sense since someone might want to select letter b. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] bang vs empty list
I wonder if we could as part of the setup call for each external somehow
infer default behaviors for each object e.g.:
something_bang() {
Error(this inlet does not support bang message\n);
}
etc.
Then if that particular object has another addmethod after it referencing
its own genuine bang (or whatever) method, such call would override the
original. I am just not sure if this is possible in the first place and
whether that could produce some misleading messages as well (e.g. I just
fixed cxc/ascseq crash when receiving a bang but this was solved without
having the bang function--this may be fixed by the aforesaid approach as
long as this is somehow possible as part of the setup function and without
having to manually alter every single external's setup function and assuming
that bang function will take precedence over the anything function).
Thoughts?
-Original Message-
From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of
Jonathan Wilkes
Sent: Monday, February 25, 2013 8:18 PM
To: pd-list
Subject: [PD] bang vs empty list
Seems like for any object that doesn't have a bang method nor list method,
an empty list silently gets discarded.
compare
[bang(
|
[sin]
to
[list(
|
[sin]
or, more likely
[bang(
|
[t a]
|
[sin]
Same for [select] and many others.
Is there a way to fix this?
-Jonathan
___
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] tooltip rfc
Just to clarify, I'm proposing to separate them completely. So there would be autotips in edit-mode that follow the mouse and that the user can only turn on or off[1]. There would additionally be a canvas tip which the user can already write to using the tip method (which could be renamed if that causes confusion). I see. As far as the canvas tips, I'm thinking just use the current syntax for the current behavior: tip 1 foo -- show foo in canvas tip tip 0 -- hide canvas tip It might be a good idea then to also extend it to reference a specific canvas (or level up kind of like window_name and patch_name and likely others do), so you could show a tip from a subpatch on the parent patch. E.g. tip 1 0 foo (0 would refer to this canvas) tip 1 2 foo (2 would be two levels above this one) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
Ico Oh, i see now... It's just that in l2ork the frame and the xlets are the foremost while in extended they are in the background so anything on the top of them can effectively cover them up. Thanks for bearing with me! I'll try dragging in a few days. András If youre looking to make cool looking GOP elements in Pd-l2Ork you can cover the frame with a custom version of ggee/image which supports png/transparency (see K-12 mode) and whose area is not indicative of the image itself so it can spill outside the GOP. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
On 02/26/2013 09:07 PM, András Murányi wrote: On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic i...@vt.edu mailto:i...@vt.edu wrote: This may be because you didn't hide gop titles, in which case pd-l2ork resizes gop size to match the text width. Yes this is indeed the case. I noticed, however, that there was no title to be displayed, meaning that with hide GOP title unchecked, the rectangle was bigger but there was no title (see attachment). And it shows the frame when it's embedded in another GOP. AFAIK embedded GOP objects have always had frames. This is why all iemguis also have frames/inlets/outlets even when embedded inside GOP. I think your background made them hard to distinguish. I could be wrong, though, but I always remember seeing those. As for the text not being displayed, can you send me the slider abstraction? It could be that since you've originally saved the abstraction inside regular pd that it did not get adjusted completely to conform to pd-l2ork's way of dealing with these. Try manually readjusting the GOP size and re-save it. It should either prevent you from resizing it below the text size or do it just fine provided you've disabled the showing of text. As for text not showing in a subpatcher even though it should, this is something I should investigate. Regarding slow redraw, can you try latest version? I fixed one major inefficiency. I'll try it as soon as I get to it. I noticed meanwhile that during the hangup, this error is thrown to the command line a few times: tcl/tk error: unknown encoding yahoo This likely refers to text encoding if you use something unusual/setup-specific. HTH András On Feb 26, 2013 6:22 PM, András Murányi muran...@gmail.com mailto:muran...@gmail.com wrote: Thanks for the reply. The hangup is literally 5 minutes, CPU is maxed out most of the time. The undo takes 5 seconds, again literally. It doesn't occur in pd-extended. Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldn’t they? Well, traditionally they don't and I think they should not. This would be consistent behavior if the borders of every element in the outer GOP subpatch would be visible. *However, I was wrong and actually this is not what's happening.* Rather, it seems that some GOP subpatches have the wrong size, and then they also show thru nested GOPs. See the attached screenshot: at the top left corder of the open subpatch, there are two GOP subpatches (Cut and Res; their guts are shown in the open subpatch window), each wider than they should be. The big gray rectangle at the bottom of the image is a large GOP subpatch itself, and the same nested GOP shows thru it. I couldn't reproduce this symptom from scratch. András On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic i...@vt.edu mailto:i...@vt.edu wrote: One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote: So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailto:Pd-list@iem.at mailing list UNSUBSCRIBE
Re: [PD] pd-l2ork feedback
On 02/26/2013 09:48 PM, Ivica Ico Bukvic wrote: AFAIK embedded GOP objects have always had frames. This is why all iemguis also have frames/inlets/outlets even when embedded inside GOP. I think your background made them hard to distinguish. I could be wrong, though, but I always remember seeing those. As for the text not being displayed, can you send me the slider abstraction? It could be that since you've originally saved the abstraction inside regular pd that it did not get adjusted completely to conform to pd-l2ork's way of dealing with these. Try manually readjusting the GOP size and re-save it. It should either prevent you from resizing it below the text size or do it just fine provided you've disabled the showing of text. As for text not showing in a subpatcher even though it should, this is something I should investigate. BTW, I just checked on pd-l2ork and everything draws just as it should even with multiply embedded GOPs (ones with text enabled show text and ones with it disabled don't. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pd-l2Ork v.20130223 now available
Apologies for x-posting. Pd-L2Ork v. 20130223 is now available with following fixes/updates/new features: *further refinements to the zoom algorithm involving gop subpatchers *made scrolling algorithm more robust *cleaned up sequencer help file *improved/sped-up gop redrawing when using non-accelerated objects *improved compatibility with 0.43 and 0.44 branch API *removed flatgui due to its buggy nature *improved modularity of the dev installer *bug fix http://sourceforge.net/tracker/?func=detailaid=3605384 *bug fix http://sourceforge.net/tracker/?func=detailaid=3605379 *updated TODO list *updated pdp_opencv to make it compile with latest version of libs *bug fix/improvement of the select object *improved fftw3 support *bugfix (http://sourceforge.net/tracker/?func=detailaid=3605257 *added fftw flag *tree clean-up *first step towards supporting wiimote plus (does not work yet) *minor version bump to distinguish it from pd-extended *added Jonathan Wilkes' canvasinfo and pdinfo externals *added additional dependency to the control file for the proper pdp build *improved deb control file and minimized conflicts with other pd distributions *2nd part of pdp/pidip update (new files) *updated sigpack and fixed freqshift~ bug *1st step in syncing latest pdp and pidip with fixes/changes to make it compile on Ubuntu 12.04 *added support for tcl/tk8.6 *improved building of gem2pdp on Arch Linux For more info see: http://l2ork.music.vt.edu/main/?page_id=56 http://puredata.info/downloads/Pd-L2Ork Please note that due to L2Ork's migration to 64-bit platform we may not provide 32-bit builds as often until we set up Launchpad or some other auto-building system. Until then, current release is available only as 64-bit. The source is buildable into deb as well as binary script-based installer using a single command provided all dependencies are satisfied. See http://l2ork.music.vt.edu/main/?page_id=56 for more info. Best wishes, Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] l2ork compile problem
/pd*bz2': No such file or directory l2ork addons... tar: l2ork_addons: Cannot stat: No such file or directory tar: ../l2ork_addons-x86_64-20130221.tar.bz2: Cannot open: Permission denied tar: Error is not recoverable: exiting now tar: Child returned status 2 tar: Exiting with failure status due to previous errors ./tar_em_up.sh: line 299: cd: l2ork_addons/: No such file or directory done. András ___ Pd-list@iem.at mailto: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 -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
Thanks for the update. I will investigate the popup and mknob. Ive just started cleaning up externals so things like these may crop up depending whether Ive used them or not. Undo redraws the patch due to the way how pd draws things so on a huge patch it may take a while. 5 seconds (needles to say 5 minutes?) is way too long, however, and I wonder if the problem lies elsewhere as Ive never had such problems on a measly atom netbook. Nested gop subpatches should show their outlines and xlets (just like number2 or toggle does as well), shouldnt they? From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of András Murányi Sent: Friday, February 22, 2013 3:34 PM To: pd-list Subject: [PD] pd-l2ork feedback So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote: So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
OK, I hunted down some problems within the gop redrawing which should streamline things even further. That said, flatgui objects like knob are chronically broken. I also tested them in the latest version of pd-extended. Try creating one knob, then another in the same window. Now delete one and crash... Tons of problems with it on other levels as well... I am really thinking about getting rid of flatgui altogether. On 02/22/2013 04:37 PM, Ivica Ico Bukvic wrote: One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote: So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pd-l2ork feedback
Popup is similar in that respect--terribly inefficient when it comes it drawing it... On 02/22/2013 08:34 PM, Ivica Ico Bukvic wrote: OK, I hunted down some problems within the gop redrawing which should streamline things even further. That said, flatgui objects like knob are chronically broken. I also tested them in the latest version of pd-extended. Try creating one knob, then another in the same window. Now delete one and crash... Tons of problems with it on other levels as well... I am really thinking about getting rid of flatgui altogether. On 02/22/2013 04:37 PM, Ivica Ico Bukvic wrote: One clarification now that I read your report more carefully. Mknob makes abstraction movement slower because this is the old/non-accelerated pd way of moving things. The new pd-l2ork model falls back on that when at least one object in the abstraction does not support accelerated moving. Once I get to fixing the mknob to support accelerated displace, this will be fixed. I am still surprised to hear this is taking 5 minutes, though. Is this an exaggeration or truly 5 minutes? Also, if you are undoing objects that are non-accelerated or complex abstractions, you are running into same problems because you are moving and redrawing non-accelerated way... Is the same slowness perceived on regular pd when moving the said abstraction? On 02/22/2013 03:34 PM, András Murányi wrote: So, I've played around with the last git, here are some things I've noticed: - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some kinds of [widget] work while others not. - [flatgui/popup] is installed by default but it throws an error when clicked on: Invalid command name pdtk_canvas_mouse. - moving a simple GOP abstraction with a single [mknob] in it takes like 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast however when the patch is simple. Undoing the movement is not instant but it is quick (~5sec). - nested GOP subpatches show off their outlines and xlets. -- Murányi András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] GUI overload
I just discovered that my apparent GUI stutter came from tear free being enabled on in my AMD/fglrx video card control panel (go figure). So, my report may not be complete/accurate. I will reenable the flag and investigate further. As for trying pd-l2ork you can always compile it using the instructions provided online which are fairly simply even for a newcomer. Best wishes, Ico -Original Message- From: Ed Kelly [mailto:morph_2...@yahoo.co.uk] Sent: Thursday, February 21, 2013 5:41 PM To: Ivica Ico Bukvic; 'Jonathan Wilkes'; 'Miller Puckette' Cc: pd-list@iem.at Subject: Re: [PD] GUI overload OK. Right now the change Miller suggested to the source code is the only way I can run my patch and have the GUI work at all, so I'm keeping my main machine equipped with this change to Pd vanilla 0.43 with libs compiled, rather than Pd-extended 0.43-4. If Miller can work out how this works, why my GUI doesn't work, and how to get the best of both worlds then great. I have another machine with Pd-extended on it, and will test the patch there as soon as I've made the new (and old) Metastudio abstractions work with 0.43. Note that I'm using a single Pd with no networking. Perhaps the way that the network objects and the GUI are implemented conflicts in some way, or creates a bottleneck somewhere, for Pd-l2ork. My Pd patch, with 45 GOP abstractions in the master patch and 4 quadtracker objects (see enclosed .ps) runs really smoothly with the patch applied, but the GUI doesn't work at all without it. Sorry, but I can't test the latest Pd-l2ork because I'm running Ubuntu 10.04. I won't upgrade now because I have pieces to finish and gigs coming up. Cheers, Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ From: Ivica Ico Bukvic i...@vt.edu To: 'Jonathan Wilkes' jancs...@yahoo.com; 'Miller Puckette' m...@ucsd.edu Cc: pd-list@iem.at Sent: Friday, 15 February 2013, 4:03 Subject: Re: [PD] GUI overload OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in heavy traffic situations gets visibly sluggish and falls behind, so to say. This still leaves the only notable difference between pd-l2ork and pd that has so far proven pd-l2ork resistant to the problems encountered below and those have to do with the way how pd-l2ork has altered both netsend/netreceive and also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues... Why is it disis_netsend/receive and not simply a fixed netsend/receive? Did you change the interface in some way? -Jonathan Those have additional features (e.g. UDP broadcast, obviously operation without gui hiccups, as well as enqueing messages and dumping them all at once) that I implemented as separate externals before forking pd-l2ork so I did it in a way that did not mess with the core pd. Since then, I fixed netsend/receive in the core part of Pd as well but kept those for backwards compatibility purposes unaltered. ___ 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] gui-plugins
- I can change the colors of the wires, but not the color a wire has when connecting one box to another, can this be changed with a tcl setting ? These are hard-coded in pd/extended. They are changeable in pd-l2ork. - is it possible to change the default/initial colors of gui-objects like bang, tgl etc through tcl or are these hardcoded in C ? These are changeable in both extended/l2ork (AFAIK). kind regards, Rob ___ 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] OT: Lightest Fastest Linux Window Manager
Unity is fine. We use it in L2Ork without any notable problems... On Feb 14, 2013, at 19:01, James Dunn ja...@4thharmonic.com wrote: I use TWM on Arch Linux but it's very basic Quoth Pagano, Patrick, on 14/02/2013 18:40: Hello I am setting up a Asus netbook for Pure Data/Gem/pidip and would like to not load the hoggish unity or even gnome seems to slow this little guy down. Can linux users suggest a window manager that might serve me best for this purpose. Thank you in Advance. Patrick Pagano, B.S, M.F.A Assistant in Digital Arts and Science Digital Media Projection and Audio Design Digital Worlds Institute University of Florida, USA (352)294-2020 ___ 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] GUI overload
OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in heavy traffic situations gets visibly sluggish and falls behind, so to say. This still leaves the only notable difference between pd-l2ork and pd that has so far proven pd-l2ork resistant to the problems encountered below and those have to do with the way how pd-l2ork has altered both netsend/netreceive and also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues... -Original Message- From: Miller Puckette [mailto:m...@ucsd.edu] Sent: Thursday, December 20, 2012 11:46 PM To: Ivica Bukvic Cc: pd-list@iem.at Subject: Re: [PD] GUI overload My worry is, I'm not sure if there's still a problem out there that the || -. + change fixes. Maybe I should try to cook up a formal definition of what working correctly should consist of :) M On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote: Miller, Pd-l2ork has this fix since your original post on the PD list and I've yet to see any regressions. Many thanks for the suggestion. That said, I've yet to understand the logic behind it ;-). P.S. I also discovered quite a while ago that netreceive had a tendency to freeze GUI permanently, likely due to asynchronous message processing. I fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a single GUI freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the temporary freeze happened and for which time has already passed, e.g. having a timer in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been enqueued while the freeze was in effect). This may have been in part due to atom cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue. HTH Best wishes, Ico On Dec 20, 2012 7:02 PM, Miller Puckette m...@ucsd.edu wrote: OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also commit the return (sys_domicrosleep(0, 1) || sys_poll_togui()) --- + change as well (somehow I think it should never be necessary to do that but I'm realizing how little I understand Pd's scheduler.) cheers M On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote: It seems that there are a number of issues here: * GUI objects sending every update, regardless of change (fixed) * arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows, and it looks like only Mac OS X is affected * all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui()) * GUI objects sending updates to GUI as fast as they receive them even tho the screen will never update faster than every ~10ms. * some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in realtime .hc On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote: OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers). Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI. Ed I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows. https://sourceforge.net/tracker/?func=detailaid=3573542group_id=5573 6atid=478070 Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you. .hc On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote: OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s on every tick unless teh GUI itself is sending hundreds of messages per second down to Pd. Reducing the average
Re: [PD] GUI overload
It makes things worse in pd-l2ork. Pd-l2ork did not need it (AFAICT) in the first place since I had the netsend/receive fixed but I tried it anyhow just to make sure and my conclusion is it makes things more sluggish gui-wise. -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Hans-Christoph Steiner Sent: Thursday, February 14, 2013 10:07 PM To: pd-list@iem.at Subject: Re: [PD] GUI overload I don't quite understand. Are you saying that this || to + change does help or does not help? .hc On 02/14/2013 09:27 PM, Ivica Ico Bukvic wrote: OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in heavy traffic situations gets visibly sluggish and falls behind, so to say. This still leaves the only notable difference between pd-l2ork and pd that has so far proven pd-l2ork resistant to the problems encountered below and those have to do with the way how pd-l2ork has altered both netsend/netreceive and also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues... -Original Message- From: Miller Puckette [mailto:m...@ucsd.edu] Sent: Thursday, December 20, 2012 11:46 PM To: Ivica Bukvic Cc: pd-list@iem.at Subject: Re: [PD] GUI overload My worry is, I'm not sure if there's still a problem out there that the || -. + change fixes. Maybe I should try to cook up a formal definition of what working correctly should consist of :) M On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote: Miller, Pd-l2ork has this fix since your original post on the PD list and I've yet to see any regressions. Many thanks for the suggestion. That said, I've yet to understand the logic behind it ;-). P.S. I also discovered quite a while ago that netreceive had a tendency to freeze GUI permanently, likely due to asynchronous message processing. I fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a single GUI freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the temporary freeze happened and for which time has already passed, e.g. having a timer in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been enqueued while the freeze was in effect). This may have been in part due to atom cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue. HTH Best wishes, Ico On Dec 20, 2012 7:02 PM, Miller Puckette m...@ucsd.edu wrote: OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also commit the return (sys_domicrosleep(0, 1) || sys_poll_togui()) --- + change as well (somehow I think it should never be necessary to do that but I'm realizing how little I understand Pd's scheduler.) cheers M On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote: It seems that there are a number of issues here: * GUI objects sending every update, regardless of change (fixed) * arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows, and it looks like only Mac OS X is affected * all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui()) * GUI objects sending updates to GUI as fast as they receive them even tho the screen will never update faster than every ~10ms. * some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in realtime .hc On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote: OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers). Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI. Ed I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows. https://sourceforge.net/tracker/?func
Re: [PD] GUI overload
OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in heavy traffic situations gets visibly sluggish and falls behind, so to say. This still leaves the only notable difference between pd-l2ork and pd that has so far proven pd-l2ork resistant to the problems encountered below and those have to do with the way how pd-l2ork has altered both netsend/netreceive and also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues... Why is it disis_netsend/receive and not simply a fixed netsend/receive? Did you change the interface in some way? -Jonathan Those have additional features (e.g. UDP broadcast, obviously operation without gui hiccups, as well as enqueing messages and dumping them all at once) that I implemented as separate externals before forking pd-l2ork so I did it in a way that did not mess with the core pd. Since then, I fixed netsend/receive in the core part of Pd as well but kept those for backwards compatibility purposes unaltered. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: absolute vs relative filepath on oggread~
On 2013-02-08 22:18, Ivica Ico Bukvic wrote: But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name. but only iemgut's [canvasname] allows you to also _rename_ a canvas under the hood. so that when you save or duplicate the patch it will show up under a new name (and possibly functionality). mdfar IOhannes iemgut's does everything pd-l2ork does plus it's been written by me :-) Now that's a bold statement :-) BTW, what is the advantage of canvasname? Seems to me that the only reason it exists is because having multiple instances of same abstractions makes it difficult to differentiate between them, which in case of pd-l2ork's preset_hub/preset_name is completely a non-issue. Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: absolute vs relative filepath on oggread~
On 02/08/2013 05:32 PM, Jonathan Wilkes wrote: - Original Message - From: Ivica Ico Bukvic i...@vt.edu To: 'Hans-Christoph Steiner' h...@at.or.at; pd-list@iem.at Cc: Sent: Friday, February 8, 2013 4:18 PM Subject: Re: [PD] Fwd: absolute vs relative filepath on oggread~ But it doesn't give you the name of the patch itself (which could be useful for auto-naming files associated with the patch, e.g. soundfiles). L2ORk's patch_name does everything getdir does (optional argument traverses structure upwards to provide you with info of patches/abstractions above it) plus gives you the patch name. So does canvasinfo: http://article.gmane.org/gmane.comp.multimedia.puredata.devel/11601/match=classinfo with a bang method that prints all the canvas attributes to the console for quick reference. Way easier for the user since each attribute is a method within a single object, with a standard interface (and if more attributes are needed it's trivial to add them without breaking anything). Also easier to develop, as adding another attribute is as simple as adding a method (as opposed to copy/pasting yet another external class, which is the equivalent of copy/pasting subpatches instead of learning to use abstractions in Pd). -Jonathan This has been added to pd-l2ork git... -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pidip
I just finished cleaning up both pdp and pidip libs to be fully auto-buildable as part of pd-l2ork (including freenect, artoolkit, opencv, etc.). There are a number of packages you need to install from launchpad in order to get all the externals to build. Stay tuned for the next release coming soon with these enhancements... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pidip
On 02/06/2013 09:36 AM, Pagano, Patrick wrote: That is supremely cool. Are there examples included for pdp_artoolkit? Students had a hard time with the fiducials at first and a simple example goes a long way. There is one help patch that I tested and it worked (albeit tracking was a bit slow, which may be because my laptop is fairly low-end notebook/netbook). It is fairly straightforward, though. Documentation both for pdp and pidip could use an overhaul, though. Currently, as I said I used the built version of pdp and it loads, when I compiled pdp_0.12-6 it gave a linking error with gsl Please let me know when you complete these, I would love to try them out. If you are using Ubuntu 12.04 64bit, I can send you binaries until I clean things up. The versions I built are pdp 0.12.7 and pidip 0.12.30. AFAICT all externals built successfully. Also when are you going to include mu for pd :-) That's a thought :-). FWIW, mu should work out-of-box with netsend/receive but the texture sharing voodoo is not implemented yet... Cheers pp -Original Message- From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Ivica Ico Bukvic Sent: Wednesday, February 06, 2013 9:27 AM Cc: pd-list@iem.at Subject: Re: [PD] pidip I just finished cleaning up both pdp and pidip libs to be fully auto-buildable as part of pd-l2ork (including freenect, artoolkit, opencv, etc.). There are a number of packages you need to install from launchpad in order to get all the externals to build. Stay tuned for the next release coming soon with these enhancements... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: Re: enhance pd-extended with pd-l2ork featues ?
On 02/06/2013 04:12 PM, Charles Goyard wrote: Charles Goyard wrote: While I'm typing, my computer is building a fresh copy of pd-l2ork with PKGBUILD to see if everything is ok. so everythings works fine with the /usr/local/ version. Except that the default.pdl2ork file is missing with the brand new PKGBUILD, so it makes it hard to have good defaults :). That is then a bug in PKGBUILD. If you use l2ork script it builds just fine. Fero, When making the PKGBUILD, please make sure to install the file pd-l2ork_git_folder/packages/linux_make/default.pdl2ork into the pd_install_folder/ (e.g. /usr/local/pd-l2ork/default.pdl2ork). You are also probably missing other file icons and shortcuts that are located in the same folder. Please investigate pd-l2ork_git_folder/l2ork_addons/tar_em_up.sh script and see what it does. Also, investigate makefiles in the pd-l2ork_git_folder/packages/linux_make/ folder to see what they do in addition to the core build scripts. Best wishes, Ico Cheers, Charles ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] enhance pd-extended with pd-l2ork featues ?
During build process, pd-l2ork gets it from: git://pd-gem.git.sourceforge.net/gitroot/pd-gem/Gem Isn't this the most up-to-date version? On 02/05/2013 04:59 PM, Hans-Christoph Steiner wrote: FYI, gem is no longer using svn, it switched to git. So Gem from SVN is out of date, unless its from the pd-extended release branch, in which case its the last release version rather than the development version. .hc On 02/05/2013 04:52 PM, Ivica Bukvic wrote: It is the latest Gem from svn, so I am not sure what is not working. Can you be more specific? On Feb 5, 2013 4:37 PM, Charles Goyard c...@fsck.fr wrote: No, it conflics with pd-extended. (just tried). btw it's awesome. Too bad Gem seems to work badly, or is it just me ? Ivica Bukvic wrote: Will it install in/usr/local, though, to prevent collision between pd-extended and pd-l2ork? ___ 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 -- Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound Intermedia Studio Director, L2Ork Linux Laptop Orchestra Head, ICAT IMPACT Studio Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Fwd: absolute vs relative filepath on oggread~
Not sure if this is off-topic, but pd-l2ork has an external called patch_name (or patchname, can't remember off top my head) which gives you both the current open patch path and filename as two separate symbols. I am sure there might be other similar externals out there, I just failed to locate them... Best wishes, Ico ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Apply missing
states. The first part o that is not hard, the second part is. But since unlimited undo is working in some parts of pd-l2ork, we at least have a working example to draw from. What do you mean by in some parts? Can you give an example of where it does not work? Setting a value in the properties of a slider. You are kidding, right? If the value changes in the UI, this should not be undoable. Otherwise, having that slider connected to a [metro 1] and random would starve memory within minutes, needless to mention make undo completely useless... ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Building pd-l2ork on arch linux 64
Thanks for all your hard work! Please see comments below. From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Fero Kiraly Sent: Sunday, January 27, 2013 8:53 AM To: pd-list@iem.at Subject: Re: [PD] Building pd-l2ork on arch linux 64 Ivica, I have good message ! pd-l2ork has been completely build on arch 64 from my new PKGBUILD. it has this last problem: If I want to install it to the system it complies about this: error: failed to commit transaction (conflicting files) pd-l2ork: /usr/bin/cyclist exists in filesystem pd-l2ork: /usr/bin/pdreceive exists in filesystem pd-l2ork: /usr/bin/pdsend exists in filesystem pd-l2ork: /usr/share/man/man1/pdreceive.1.gz exists in filesystem pd-l2ork: /usr/share/man/man1/pdsend.1.gz exists in filesystem That is because both versions include these files. My understanding is that pd-extended packages this as a separate package pd-utils. How to handle this is not clear. For right now it is a conflict (as it should be) since both packages provide the same binary. all of the errors are conflicting files from pd-extended. If I uninstall pd-extended, everything goes well and I have functional pd-l2ork in the system. How to resolve this ? For right now exactly as you did, or install pd-l2ork using binary installer into /usr/local. Pd-extended does not support this as far as I could tell (it only supports install in /usr folder), so you would have to install pd-l2ork this way. next.. you have resolved problem with gem2pdp, but I have to run aclocal in this folder separately before building process, because in your script is only cd gem2pdp autoconf something changed ? Wait, are you saying that if you: cd externals/ make gem2pdp this fails unless you manually run aclocal? and finally I have to patch the pd/src/configure.in for tcl/tk8.6, and I think it could be added officially here is the patch file: Thanks for providing the patch. Does this mess with older versions, namely 8.5 or does this script work for both? *** configure.in2013-01-23 19:46:22.0 +0100 --- configure.in.new 2013-01-23 19:54:57.476420874 +0100 *** *** 149,154 --- 149,155 #exit -1 fi + AC_CHECK_LIB(tcl8.6, main,, AC_CHECK_LIB(tcl85, main,, AC_CHECK_LIB(tcl8.5, main,, AC_CHECK_LIB(tcl84, main,, *** *** 156,171 AC_CHECK_LIB(tcl8.3, main,, AC_CHECK_LIB(tcl8.2, main,, AC_CHECK_LIB(tcl8.0, main,, ! echo no tcl library found; exit 1))) AC_CHECK_LIB(tk85, main,, ! AC_CHECK_LIB(tk8.5, main,, AC_CHECK_LIB(tk84, main,, AC_CHECK_LIB(tk8.4, main,, AC_CHECK_LIB(tk8.3, main,, AC_CHECK_LIB(tk8.2, main,, AC_CHECK_LIB(tk8.0, main,, ! echo no tk library found; exit 1))) if test x$tk != xno; then --- 157,173 AC_CHECK_LIB(tcl8.3, main,, AC_CHECK_LIB(tcl8.2, main,, AC_CHECK_LIB(tcl8.0, main,, ! echo no tcl library found; exit 1 + AC_CHECK_LIB(tk8.6, main,, AC_CHECK_LIB(tk85, main,, ! AC_CHECK_LIB(tk8.5, main,, AC_CHECK_LIB(tk84, main,, AC_CHECK_LIB(tk8.4, main,, AC_CHECK_LIB(tk8.3, main,, AC_CHECK_LIB(tk8.2, main,, AC_CHECK_LIB(tk8.0, main,, ! echo no tk library found; exit 1 fk. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
