Re: [PD] fexpr~
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-24 07:18, Billy King wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? [fexpr~] allows you to access past samples, so you can build filters and the like. [expr~] only works on the current input samples. mfasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCHmIkACgkQkX2Xpv6ydvQVEQCbB7OZl0FxsOasP8lVJbjXcaNi /4AAn10M8WuHEUnhKCY6Sl3FWdNz2p1S =N467 -END PGP SIGNATURE- ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fexpr~
Check this out http://crca.ucsd.edu/~syadegar/expr.html On Wed, Oct 24, 2012 at 8:18 AM, Billy King billyking...@yahoo.ca wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? Thank you! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] new version: Extended View Toolkit v0.4 Rotterdam
Hello All! We proudly announce the new version of ExtendedViewToolkit - the PureData/GEM abstraction library for panoramic image/video creation and projection mapping. It has been a long, but productive time since our last release. Tons of new features and fixes wait for being discovered by you. This new version was mainly done during a residency at moddr_/WORM in Rotterdam. Amongst other changes, you are looking on a completely re-designed storage-solution, that enables you to create scene-based video-mapping setups - with the possibility to add transitions between your scenes. Within each scene, you can automate basically every parameter in every module of the toolkit individually. We made a small technical teaser, to show what's possible with the scenes: http://vimeo.com/51567993 In addition to our multi-camera panoramic content solution, we integrated a module for creating 360-degree panoramic content made with spherical, one camera based, lens- or mirror-systems. Also, a new video player with instant and saveable controls for in/out-points, fade-times and loop, waits for being used within your performance. On the projection-side we added a module with 5x5 cornerpoints to allow more detailed settings when projecting on uneven surfaces with just one projection module. Furthermore we implemented a function to adjust the perspective distortion into the projection modules. We sticked to our fear of externals and made the whole toolkit out of plain PD and GEM without any other external libraries. For the usage of the remote-control features we recommend the usage of mrpeach´s OSC library. We tested the toolkit on different machines, and did not have any issues on Linux, OSX 10.6.8, 10.7.1 and also on Windows 7. If you discover any problems, please get in touch with us. Thanks to all the people who constantly support the development of the toolkit, especially Cyrille Henry, IOhannes, Seppo, WalterBirgit of moddr and Patrick Pagano. Download it here: https://github.com/extendedview/extended_view_toolkit If you use it, we strongly encourage you to send us links, videos, images, etc. of your projects. We are amazingly interested to see what you create! Cheers, Peter Marian http://extendedview.mur.at ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Translating Puckette Lectures into Spanish (Fero Kiraly)
hi Fero and list i wonder where those lectures might be. kindest ./d -- Message: 1 Date: Tue, 23 Oct 2012 22:41:46 +0200 From: Fero Kiraly fero.kir...@gmail.com Subject: Re: [PD] Translating Puckette Lectures into Spanish To: pd-list@iem.at Message-ID: CAM6dkpVa5JfyWF3mfr9-5Z_+0Ms=fmcqwblhldj3jq80zyv...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I am not native english speaker so I make srt file of first course from transcripts file. It is now more understandable for me and maybe for another of you It takes me a long time. It is a good idea to do it in pd community... so if anybody can prepare srt from other courses will be great ! -- Fero Kiraly www.cluster-ensemble.com -- http://www.fastmail.fm - Access your email from home and the web ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Translating Puckette Lectures into Spanish (Fero Kiraly)
here : http://pd-la.info/pd-media/miller-puckette-mus171-videos/ also the transcripts. 2012/10/24 slew52 three...@ml1.net hi Fero and list i wonder where those lectures might be. kindest ./d -- Message: 1 Date: Tue, 23 Oct 2012 22:41:46 +0200 From: Fero Kiraly fero.kir...@gmail.com Subject: Re: [PD] Translating Puckette Lectures into Spanish To: pd-list@iem.at Message-ID: CAM6dkpVa5JfyWF3mfr9-5Z_+0Ms= fmcqwblhldj3jq80zyv...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I am not native english speaker so I make srt file of first course from transcripts file. It is now more understandable for me and maybe for another of you It takes me a long time. It is a good idea to do it in pd community... so if anybody can prepare srt from other courses will be great ! -- Fero Kiraly www.cluster-ensemble.com -- http://www.fastmail.fm - Access your email from home and the web -- Fero Kiraly www.cluster-ensemble.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] Pd-extended 0.43.4 beta release, its almost done!
There is also a win7 64bit machine already ready and online waiting to be set up and administered. Who wants to take this on should get in touch with Hans-Christoph and/or me. If there is demand we could also set up a windows 8 machine (yes, microsoft is giving business and educaton customers win8 already) m. Am 23.10.2012 um 05:34 schrieb Hans-Christoph Steiner h...@at.or.at: So in a little burst of activity, there has been new work on the Pd-extended 0.43 release. A bunch of bugs have been fixed, a new Windows XP build server is up and running, a couple of bugs are still outstanding. Overall, things are looking good and ready to go! Unless you are affected by one of the bugs listed below, I think that this beta version is already much better than the last release. You can get it here: https://puredata.info/downloads/pd-extended/releases/0.43.4 If you are running Ubuntu or Linux Mint (lucid thru quantal), you can add this PPA to automatically find and install Pd-extended beta updates: https://launchpad.net/~eighthave/+archive/pd-extended/ Running this command in the Terminal is the easiest way to add this PPA to your machine: sudo add-apt-repository ppa:eighthave/pd-extended Unfixed bugs These are the bugs that are not yet fixed. If you can help with them we appreciate all the help we can get. GUIs not updating well on parent patch https://sourceforge.net/tracker/?func=detailaid=3573542group_id=55736atid=478070 Mac OS X: gem 0.93 does not play .mpg files https://sourceforge.net/tracker/?func=detailaid=3517368group_id=64325atid=507079 Windows: the autotips are in a very small font https://sourceforge.net/tracker/?func=detailaid=3526086group_id=55736atid=478070 Windows: canvas properties window is not focused when started https://sourceforge.net/tracker/?func=detailaid=3577400group_id=55736atid=478070 ___ Pd-announce mailing list pd-annou...@iem.at http://lists.puredata.info/listinfo/pd-announce ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] fexpr~
- Original Message - From: IOhannes m zmoelnig zmoel...@iem.at To: pd-list@iem.at Cc: Sent: Wednesday, October 24, 2012 3:28 AM Subject: Re: [PD] fexpr~ -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-24 07:18, Billy King wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? [fexpr~] allows you to access past samples, so you can build filters and the like. [expr~] only works on the current input samples. [fexpr~] allows you to access past samples from both the input and output for the _current_ block and pads with zeros when it tries to go past the beginning of the block. In other words, $x1[-3] will be guaranteed to be zero for the first three samples of the block that [fexpr~] is computing. Correct? -Jonathan mfasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCHmIkACgkQkX2Xpv6ydvQVEQCbB7OZl0FxsOasP8lVJbjXcaNi /4AAn10M8WuHEUnhKCY6Sl3FWdNz2p1S =N467 -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
Re: [PD] fexpr~
Also see: doc/5.reference/fexpr~-help.pd Or ctrl-b - Pure Data - 5.reference - fexpr~-help.pd Still not sure how to make that come up in Pd-extended by default. [expr]/[expr~]/[fexpr~] all point to expr-help.pd From: Alexandros Drymonitis adr...@gmail.com To: Billy King billyking...@yahoo.ca Cc: PD List pd-list@iem.at Sent: Wednesday, October 24, 2012 5:05 AM Subject: Re: [PD] fexpr~ Check this out http://crca.ucsd.edu/~syadegar/expr.html On Wed, Oct 24, 2012 at 8:18 AM, Billy King billyking...@yahoo.ca wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? Thank you! ___ 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] close all patches on quit sourceforge patch
Hans and Iohannes, The following is FYI. Several months ago I integrated the close all patches before quitting patch in pd-l2ork and since then I've been experiencing extremely sporadic crashes on close that would hang pd-l2ork. Now, I am not sure this is because of architectural differences between regular pd and pd-l2ork but I doubt it since most of the said components are very similar if not identical. The bottom line is this only occurs on very low-powered machines (e.g. netbook) and relatively large patches and even then it does so very sporadically. Consequently, I implemented an improvement to the closing mechanism that consists of 2 additional steps and apparently alleviates said problems entirely: 1) disable further redraws (this prevents calling functions that may be referencing null pointers)--I have a special global var for this which is also being used to optimize redrawing (many actions in pd-l2ork are several times faster than regular pd as a result of this implementation--just look for do_not_redraw call in the source if curious) 2) suspend dsp before going through the patches (all sub-patches try to suspend it and resume it but for some reason, due to asynchronous nature of communication between tcl and c funny things occasionally happen on low-powered machines, so this way we ensure it is entirely off throughout the whole destruction process) Hope this helps! 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] fexpr~
Great! Thanks That is what I was hoping How do you access a previous sample exactly? From: IOhannes m zmoelnig zmoel...@iem.at To: pd-list@iem.at Sent: Wednesday, October 24, 2012 3:28:09 AM Subject: Re: [PD] fexpr~ -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-24 07:18, Billy King wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? [fexpr~] allows you to access past samples, so you can build filters and the like. [expr~] only works on the current input samples. mfasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCHmIkACgkQkX2Xpv6ydvQVEQCbB7OZl0FxsOasP8lVJbjXcaNi /4AAn10M8WuHEUnhKCY6Sl3FWdNz2p1S =N467 -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
Re: [PD] fexpr~
Oh Great! Got my answer here. Thank you all From: Alexandros Drymonitis adr...@gmail.com To: Billy King billyking...@yahoo.ca Cc: PD List pd-list@iem.at Sent: Wednesday, October 24, 2012 5:05:44 AM Subject: Re: [PD] fexpr~ Check this out http://crca.ucsd.edu/~syadegar/expr.html On Wed, Oct 24, 2012 at 8:18 AM, Billy King billyking...@yahoo.ca wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? Thank you! ___ 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] fexpr~
Right-click on the object and it will show you a common help patch for expr, expr~, and fexpr~ that has an example of the syntax. From: Billy King billyking...@yahoo.ca To: PD List pd-list@iem.at Sent: Wednesday, October 24, 2012 8:19 PM Subject: Re: [PD] fexpr~ Great! Thanks That is what I was hoping How do you access a previous sample exactly? From: IOhannes m zmoelnig zmoel...@iem.at To: pd-list@iem.at Sent: Wednesday, October 24, 2012 3:28:09 AM Subject: Re: [PD] fexpr~ -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-10-24 07:18, Billy King wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? [fexpr~] allows you to access past samples, so you can build filters and the like. [expr~] only works on the current input samples. mfasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCHmIkACgkQkX2Xpv6ydvQVEQCbB7OZl0FxsOasP8lVJbjXcaNi /4AAn10M8WuHEUnhKCY6Sl3FWdNz2p1S =N467 -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] close all patches on quit sourceforge patch
Thanks for that info. Sounds like a good idea in general. I personally can't think of any reason why the DSP would need to be on during the quitting. But for the 'redraw' part, that depends. If it is literally only redrawing that is suspended, that would be fine. But if its all Pd--GUI communications, that will probably cause problems. .hc On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote: Hans and Iohannes, The following is FYI. Several months ago I integrated the close all patches before quitting patch in pd-l2ork and since then I've been experiencing extremely sporadic crashes on close that would hang pd-l2ork. Now, I am not sure this is because of architectural differences between regular pd and pd-l2ork but I doubt it since most of the said components are very similar if not identical. The bottom line is this only occurs on very low-powered machines (e.g. netbook) and relatively large patches and even then it does so very sporadically. Consequently, I implemented an improvement to the closing mechanism that consists of 2 additional steps and apparently alleviates said problems entirely: 1) disable further redraws (this prevents calling functions that may be referencing null pointers)--I have a special global var for this which is also being used to optimize redrawing (many actions in pd-l2ork are several times faster than regular pd as a result of this implementation--just look for do_not_redraw call in the source if curious) 2) suspend dsp before going through the patches (all sub-patches try to suspend it and resume it but for some reason, due to asynchronous nature of communication between tcl and c funny things occasionally happen on low-powered machines, so this way we ensure it is entirely off throughout the whole destruction process) Hope this helps! 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] close all patches on quit sourceforge patch
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Thanks for that info. Sounds like a good idea in general. I personally
can't
think of any reason why the DSP would need to be on during the quitting.
But
for the 'redraw' part, that depends. If it is literally only redrawing
that
is suspended, that would be fine. But if its all Pd--GUI communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before quitting
patch
in pd-l2ork and since then I've been experiencing extremely sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is because of
architectural differences between regular pd and pd-l2ork but I doubt it
since most of the said components are very similar if not identical.
The bottom line is this only occurs on very low-powered machines (e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the closing
mechanism that consists of 2 additional steps and apparently alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that may be
referencing null pointers)--I have a special global var for this which is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches try to
suspend it and resume it but for some reason, due to asynchronous nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off throughout
the whole destruction process)
Hope this helps!
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] fexpr~
I just committed a fix so that each object will now use their own help patches, instead of all using expr-help.pd: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16490 .hc On 10/24/2012 04:10 PM, Jonathan Wilkes wrote: Also see: doc/5.reference/fexpr~-help.pd Or ctrl-b - Pure Data - 5.reference - fexpr~-help.pd Still not sure how to make that come up in Pd-extended by default. [expr]/[expr~]/[fexpr~] all point to expr-help.pd From: Alexandros Drymonitis adr...@gmail.com To: Billy King billyking...@yahoo.ca Cc: PD List pd-list@iem.at Sent: Wednesday, October 24, 2012 5:05 AM Subject: Re: [PD] fexpr~ Check this out http://crca.ucsd.edu/~syadegar/expr.html On Wed, Oct 24, 2012 at 8:18 AM, Billy King billyking...@yahoo.ca wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? Thank you! ___ 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] close all patches on quit sourceforge patch
Stack overflow usually comes from recursiveness in patches until Pd's stack
overflows, or at least that's my experience of that error.
The pdtk_post logic has changed a lot in 0.43 with drastic improvements. You
can now post 1000 lines/sec and still patch in Pd.
In related work, I've been playing around with making array redrawing respect
the Tk event loop more. Basically, each draw command you send gets queued
until the event loop executes it. But for something like an array, there is
no reason to draw multiple times in a single loop, so when a new draw command
gets posted, it cancels the previous one if it hasn't run already. That is
the key to what made pdtk_post so much faster as well. Another part of that
is using after idle so that Tk doesn't drop everything to try to run that
command, but instead queues it to happen in a big chunk.
You can see the first stab at this work for arrays in the attached patches.
The first patch is only there because it needs to be applied for the 2nd patch
to apply cleanly. They apply to pure-data.git master.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Thanks for that info. Sounds like a good idea in general. I personally
can't
think of any reason why the DSP would need to be on during the quitting.
But
for the 'redraw' part, that depends. If it is literally only redrawing
that
is suspended, that would be fine. But if its all Pd--GUI communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before quitting
patch
in pd-l2ork and since then I've been experiencing extremely sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is because of
architectural differences between regular pd and pd-l2ork but I doubt it
since most of the said components are very similar if not identical.
The bottom line is this only occurs on very low-powered machines (e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the closing
mechanism that consists of 2 additional steps and apparently alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that may be
referencing null pointers)--I have a special global var for this which is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches try to
suspend it and resume it but for some reason, due to asynchronous nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off throughout
the whole destruction process)
Hope this helps!
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/
From f994eb249daf8dac552ea97e9f40ed0cf32456fa Mon Sep 17 00:00:00 2001
From: Hans-Christoph Steiner h...@eds.org
Date: Mon, 8 Oct 2012 10:56:24 -0400
Subject: [PATCH 1/2] remove pdtk_array.tcl, its unused and is old duplicates
of dialog_array.tcl
---
po/Makefile.am |2 +-
tcl/Makefile.am|2 +-
tcl/pdtk_array.tcl | 346
tcl/pkgIndex.tcl |1 -
4 files changed, 2 insertions(+), 349 deletions(-)
delete mode 100644 tcl/pdtk_array.tcl
diff --git a/po/Makefile.am b/po/Makefile.am
index da38360..0dd847f 100644
--- a/po/Makefile.am
+++ b/po/Makefile.am
@@ -9,7 +9,7 @@ if MACOSX
PATH := /sw/lib/gettext-tools-0.17/bin:${PATH}
endif
-TCLFILES = apple_events.tcl dialog_canvas.tcl dialog_gatom.tcl dialog_path.tcl pd_bindings.tcl pd_menus.tcl pdwindow.tcl scrollboxwindow.tcl AppMain.tcl dialog_data.tcl dialog_iemgui.tcl dialog_startup.tcl pd_connect.tcl pdtk_array.tcl pkgIndex.tcl wheredoesthisgo.tcl dialog_array.tcl dialog_find.tcl dialog_message.tcl helpbrowser.tcl pdtk_canvas.tcl pkg_mkIndex.tcl dialog_audio.tcl dialog_font.tcl dialog_midi.tcl opt_parser.tcl pd_menucommands.tcl pdtk_text.tcl scrollbox.tcl pd_guiprefs.tcl
+TCLFILES = apple_events.tcl dialog_canvas.tcl dialog_gatom.tcl dialog_path.tcl pd_bindings.tcl pd_menus.tcl pdwindow.tcl scrollboxwindow.tcl AppMain.tcl dialog_data.tcl dialog_iemgui.tcl
Re: [PD] close all patches on quit sourceforge patch
I just tried the latest pd-l2ork from git, and it doesn't seem to start
correctly. I did:
cd pd/src
aclocal
autoconf
./configure
make
../bin/pd-l2ork
I also tried:
cd ../bin
./pd-l2ork
All I got was a great square window with no menu. I'm on Linux Mint 13 Maya
amd64, which is basically Ubuntu/Precise.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Thanks for that info. Sounds like a good idea in general. I personally
can't
think of any reason why the DSP would need to be on during the quitting.
But
for the 'redraw' part, that depends. If it is literally only redrawing
that
is suspended, that would be fine. But if its all Pd--GUI communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before quitting
patch
in pd-l2ork and since then I've been experiencing extremely sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is because of
architectural differences between regular pd and pd-l2ork but I doubt it
since most of the said components are very similar if not identical.
The bottom line is this only occurs on very low-powered machines (e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the closing
mechanism that consists of 2 additional steps and apparently alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that may be
referencing null pointers)--I have a special global var for this which is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches try to
suspend it and resume it but for some reason, due to asynchronous nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off throughout
the whole destruction process)
Hope this helps!
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] close all patches on quit sourceforge patch
If you are not installing it onto system, copy TCL files into the pd/bin
dir. Remember, this is a fork of 0.42.
On Oct 24, 2012 9:07 PM, Hans-Christoph Steiner h...@at.or.at wrote:
I just tried the latest pd-l2ork from git, and it doesn't seem to start
correctly. I did:
cd pd/src
aclocal
autoconf
./configure
make
../bin/pd-l2ork
I also tried:
cd ../bin
./pd-l2ork
All I got was a great square window with no menu. I'm on Linux Mint 13
Maya
amd64, which is basically Ubuntu/Precise.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Thanks for that info. Sounds like a good idea in general. I personally
can't
think of any reason why the DSP would need to be on during the quitting.
But
for the 'redraw' part, that depends. If it is literally only redrawing
that
is suspended, that would be fine. But if its all Pd--GUI
communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before quitting
patch
in pd-l2ork and since then I've been experiencing extremely sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is because
of
architectural differences between regular pd and pd-l2ork but I doubt
it
since most of the said components are very similar if not identical.
The bottom line is this only occurs on very low-powered machines (e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the closing
mechanism that consists of 2 additional steps and apparently alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that may be
referencing null pointers)--I have a special global var for this which
is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches try to
suspend it and resume it but for some reason, due to asynchronous
nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off
throughout
the whole destruction process)
Hope this helps!
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] fexpr~
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: pd-list@iem.at Cc: Sent: Wednesday, October 24, 2012 8:54 PM Subject: Re: [PD] fexpr~ I just committed a fix so that each object will now use their own help patches, instead of all using expr-help.pd: Sounds good! Is it possible to put a line somewhere in Pd-extended so that it removes the old help patches in the expr lib? Then it will find the new ones in 5.reference. -Jonathan http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16490 .hc On 10/24/2012 04:10 PM, Jonathan Wilkes wrote: Also see: doc/5.reference/fexpr~-help.pd Or ctrl-b - Pure Data - 5.reference - fexpr~-help.pd Still not sure how to make that come up in Pd-extended by default. [expr]/[expr~]/[fexpr~] all point to expr-help.pd From: Alexandros Drymonitis adr...@gmail.com To: Billy King billyking...@yahoo.ca Cc: PD List pd-list@iem.at Sent: Wednesday, October 24, 2012 5:05 AM Subject: Re: [PD] fexpr~ Check this out http://crca.ucsd.edu/~syadegar/expr.html On Wed, Oct 24, 2012 at 8:18 AM, Billy King billyking...@yahoo.ca wrote: could anyone help by explaining the use of the fexpr~? how is it different from the expr~ ? Thank you! ___ 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] close all patches on quit sourceforge patch
I did:
cd pd/
cp tcl/*.tcl bin/
cd bin
./pd-l2ork
and got the same result:
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans Mono}
normal
set pd_whichmidiapi 2
.hc
On 10/24/2012 10:16 PM, Ivica Bukvic wrote:
If you are not installing it onto system, copy TCL files into the pd/bin
dir. Remember, this is a fork of 0.42.
On Oct 24, 2012 9:07 PM, Hans-Christoph Steiner h...@at.or.at wrote:
I just tried the latest pd-l2ork from git, and it doesn't seem to start
correctly. I did:
cd pd/src
aclocal
autoconf
./configure
make
../bin/pd-l2ork
I also tried:
cd ../bin
./pd-l2ork
All I got was a great square window with no menu. I'm on Linux Mint 13
Maya
amd64, which is basically Ubuntu/Precise.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Thanks for that info. Sounds like a good idea in general. I personally
can't
think of any reason why the DSP would need to be on during the quitting.
But
for the 'redraw' part, that depends. If it is literally only redrawing
that
is suspended, that would be fine. But if its all Pd--GUI
communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before quitting
patch
in pd-l2ork and since then I've been experiencing extremely sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is because
of
architectural differences between regular pd and pd-l2ork but I doubt
it
since most of the said components are very similar if not identical.
The bottom line is this only occurs on very low-powered machines (e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the closing
mechanism that consists of 2 additional steps and apparently alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that may be
referencing null pointers)--I have a special global var for this which
is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches try to
suspend it and resume it but for some reason, due to asynchronous
nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off
throughout
the whole destruction process)
Hope this helps!
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] close all patches on quit sourceforge patch
You forgot pd.tk...
On Oct 24, 2012 10:52 PM, Hans-Christoph Steiner h...@at.or.at wrote:
I did:
cd pd/
cp tcl/*.tcl bin/
cd bin
./pd-l2ork
and got the same result:
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans
Mono}
normal
set pd_whichmidiapi 2
.hc
On 10/24/2012 10:16 PM, Ivica Bukvic wrote:
If you are not installing it onto system, copy TCL files into the pd/bin
dir. Remember, this is a fork of 0.42.
On Oct 24, 2012 9:07 PM, Hans-Christoph Steiner h...@at.or.at wrote:
I just tried the latest pd-l2ork from git, and it doesn't seem to start
correctly. I did:
cd pd/src
aclocal
autoconf
./configure
make
../bin/pd-l2ork
I also tried:
cd ../bin
./pd-l2ork
All I got was a great square window with no menu. I'm on Linux Mint 13
Maya
amd64, which is basically Ubuntu/Precise.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all
gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
Thanks for that info. Sounds like a good idea in general. I
personally
can't
think of any reason why the DSP would need to be on during the
quitting.
But
for the 'redraw' part, that depends. If it is literally only
redrawing
that
is suspended, that would be fine. But if its all Pd--GUI
communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before quitting
patch
in pd-l2ork and since then I've been experiencing extremely sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is because
of
architectural differences between regular pd and pd-l2ork but I doubt
it
since most of the said components are very similar if not identical.
The bottom line is this only occurs on very low-powered machines
(e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the
closing
mechanism that consists of 2 additional steps and apparently
alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that may
be
referencing null pointers)--I have a special global var for this
which
is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches try
to
suspend it and resume it but for some reason, due to asynchronous
nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off
throughout
the whole destruction process)
Hope this helps!
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
[PD] Translator's/Subtitlers resources at http://newblankets.org/MUS171_supplements/MUS171_transcripts/
.txt : English only, with 15s time-codes embedded .doc: Table format with timecodes duplicated, for interlinear(synched) translation .html Table format with timecodes duplicated, for interlinear(synched) translation You will note that only Lectures 1,2,3 are all tidied up this way so far. The remaining lectures (4-20) will be completed ASAP and made available at this same location. Also it appears to be true that the sweep to make .doc and .html files keeps uncovering errors in the original transcrips. So we fix as we go and the files at http://newblankets.org/MUS171_supplements/MUS171_transcripts/ will be kept updates as always latest best effort. Joe ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] close all patches on quit sourceforge patch
Hmm, something different, but still not running:
hans@palatschinken bin $ cp ../src/pd.tk .
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans Mono}
normal
set pd_whichmidiapi 2
tcl: /media/share/code/pd-l2ork/pd/bin/pd.tk: can't open script
^CPd: signal 2
hans@palatschinken bin $ ls -l /media/share/code/pd-l2ork/pd/bin/pd.tk
-rwxr-xr-x 1 hans hans 289074 Oct 24 23:55
/media/share/code/pd-l2ork/pd/bin/pd.tk
On 10/24/2012 10:56 PM, Ivica Bukvic wrote:
You forgot pd.tk...
On Oct 24, 2012 10:52 PM, Hans-Christoph Steiner h...@at.or.at wrote:
I did:
cd pd/
cp tcl/*.tcl bin/
cd bin
./pd-l2ork
and got the same result:
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans
Mono}
normal
set pd_whichmidiapi 2
.hc
On 10/24/2012 10:16 PM, Ivica Bukvic wrote:
If you are not installing it onto system, copy TCL files into the pd/bin
dir. Remember, this is a fork of 0.42.
On Oct 24, 2012 9:07 PM, Hans-Christoph Steiner h...@at.or.at wrote:
I just tried the latest pd-l2ork from git, and it doesn't seem to start
correctly. I did:
cd pd/src
aclocal
autoconf
./configure
make
../bin/pd-l2ork
I also tried:
cd ../bin
./pd-l2ork
All I got was a great square window with no menu. I'm on Linux Mint 13
Maya
amd64, which is basically Ubuntu/Precise.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all
gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
Thanks for that info. Sounds like a good idea in general. I
personally
can't
think of any reason why the DSP would need to be on during the
quitting.
But
for the 'redraw' part, that depends. If it is literally only
redrawing
that
is suspended, that would be fine. But if its all Pd--GUI
communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before quitting
patch
in pd-l2ork and since then I've been experiencing extremely sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is because
of
architectural differences between regular pd and pd-l2ork but I doubt
it
since most of the said components are very similar if not identical.
The bottom line is this only occurs on very low-powered machines
(e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the
closing
mechanism that consists of 2 additional steps and apparently
alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that may
be
referencing null pointers)--I have a special global var for this
which
is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches try
to
suspend it and resume it but for some reason, due to asynchronous
nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off
throughout
the whole destruction process)
Hope this helps!
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] close all patches on quit sourceforge patch
Do you have tkpng installed as per instructions on pd-l2ork's webpage?
On Oct 24, 2012 11:57 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Hmm, something different, but still not running:
hans@palatschinken bin $ cp ../src/pd.tk .
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans
Mono}
normal
set pd_whichmidiapi 2
tcl: /media/share/code/pd-l2ork/pd/bin/pd.tk: can't open script
^CPd: signal 2
hans@palatschinken bin $ ls -l /media/share/code/pd-l2ork/pd/bin/pd.tk
-rwxr-xr-x 1 hans hans 289074 Oct 24 23:55
/media/share/code/pd-l2ork/pd/bin/pd.tk
On 10/24/2012 10:56 PM, Ivica Bukvic wrote:
You forgot pd.tk...
On Oct 24, 2012 10:52 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
I did:
cd pd/
cp tcl/*.tcl bin/
cd bin
./pd-l2ork
and got the same result:
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans
Mono}
normal
set pd_whichmidiapi 2
.hc
On 10/24/2012 10:16 PM, Ivica Bukvic wrote:
If you are not installing it onto system, copy TCL files into the
pd/bin
dir. Remember, this is a fork of 0.42.
On Oct 24, 2012 9:07 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
I just tried the latest pd-l2ork from git, and it doesn't seem to
start
correctly. I did:
cd pd/src
aclocal
autoconf
./configure
make
../bin/pd-l2ork
I also tried:
cd ../bin
./pd-l2ork
All I got was a great square window with no menu. I'm on Linux Mint
13
Maya
amd64, which is basically Ubuntu/Precise.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all
gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
Thanks for that info. Sounds like a good idea in general. I
personally
can't
think of any reason why the DSP would need to be on during the
quitting.
But
for the 'redraw' part, that depends. If it is literally only
redrawing
that
is suspended, that would be fine. But if its all Pd--GUI
communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before
quitting
patch
in pd-l2ork and since then I've been experiencing extremely
sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is
because
of
architectural differences between regular pd and pd-l2ork but I
doubt
it
since most of the said components are very similar if not
identical.
The bottom line is this only occurs on very low-powered machines
(e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the
closing
mechanism that consists of 2 additional steps and apparently
alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that
may
be
referencing null pointers)--I have a special global var for this
which
is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this
implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches
try
to
suspend it and resume it but for some reason, due to asynchronous
nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off
throughout
the whole destruction process)
Hope this helps!
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] close all patches on quit sourceforge patch
yup:
hans@palatschinken bin $ dpkg -l tkpng
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++---
ii tkpng0.9-1ubuntu1 PNG photo image support to Tcl/Tk
Does it not work with Tcl/Tk 8.5?
hans@palatschinken bin $ tclsh
% info patchlevel
8.5.11
.hc
On 10/25/2012 12:11 AM, Ivica Bukvic wrote:
Do you have tkpng installed as per instructions on pd-l2ork's webpage?
On Oct 24, 2012 11:57 PM, Hans-Christoph Steiner h...@at.or.at wrote:
Hmm, something different, but still not running:
hans@palatschinken bin $ cp ../src/pd.tk .
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans
Mono}
normal
set pd_whichmidiapi 2
tcl: /media/share/code/pd-l2ork/pd/bin/pd.tk: can't open script
^CPd: signal 2
hans@palatschinken bin $ ls -l /media/share/code/pd-l2ork/pd/bin/pd.tk
-rwxr-xr-x 1 hans hans 289074 Oct 24 23:55
/media/share/code/pd-l2ork/pd/bin/pd.tk
On 10/24/2012 10:56 PM, Ivica Bukvic wrote:
You forgot pd.tk...
On Oct 24, 2012 10:52 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
I did:
cd pd/
cp tcl/*.tcl bin/
cd bin
./pd-l2ork
and got the same result:
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3
set pd_whichmidiapi 2
pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007
} { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans
Mono}
normal
set pd_whichmidiapi 2
.hc
On 10/24/2012 10:16 PM, Ivica Bukvic wrote:
If you are not installing it onto system, copy TCL files into the
pd/bin
dir. Remember, this is a fork of 0.42.
On Oct 24, 2012 9:07 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
I just tried the latest pd-l2ork from git, and it doesn't seem to
start
correctly. I did:
cd pd/src
aclocal
autoconf
./configure
make
../bin/pd-l2ork
I also tried:
cd ../bin
./pd-l2ork
All I got was a great square window with no menu. I'm on Linux Mint
13
Maya
amd64, which is basically Ubuntu/Precise.
.hc
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:
It is only the draw command, not the communication...
BTW do either of you know why one would be getting pdtk_post { stack
overflow } messages? Doors that mean the cpu is unable to handle all
gui
requests?
On Oct 24, 2012 8:32 PM, Hans-Christoph Steiner h...@at.or.at
wrote:
Thanks for that info. Sounds like a good idea in general. I
personally
can't
think of any reason why the DSP would need to be on during the
quitting.
But
for the 'redraw' part, that depends. If it is literally only
redrawing
that
is suspended, that would be fine. But if its all Pd--GUI
communications,
that will probably cause problems.
.hc
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:
Hans and Iohannes,
The following is FYI.
Several months ago I integrated the close all patches before
quitting
patch
in pd-l2ork and since then I've been experiencing extremely
sporadic
crashes
on close that would hang pd-l2ork. Now, I am not sure this is
because
of
architectural differences between regular pd and pd-l2ork but I
doubt
it
since most of the said components are very similar if not
identical.
The bottom line is this only occurs on very low-powered machines
(e.g.
netbook) and relatively large patches and even then it does so very
sporadically. Consequently, I implemented an improvement to the
closing
mechanism that consists of 2 additional steps and apparently
alleviates
said
problems entirely:
1) disable further redraws (this prevents calling functions that
may
be
referencing null pointers)--I have a special global var for this
which
is
also being used to optimize redrawing (many actions in pd-l2ork are
several
times faster than regular pd as a result of this
implementation--just
look
for do_not_redraw call in the source if curious)
2) suspend dsp before going through the patches (all sub-patches
try
to
suspend it and resume it but for some reason, due to asynchronous
nature
of
communication between tcl and c funny things occasionally happen on
low-powered machines, so this way we ensure it is entirely off
throughout
the whole destruction process)
Hope this helps!
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 -
