Hi all,
I have only 2 weeks left in the vicinity of my usual collection of testing machines (will be in New York Sept 1 - Jan. 1!) and so should probably try to get 0.43 finalized. I have several bugs to work on but I think the whole thing is ready to put out compiled "test versions" for people to exercise.
I'll try not to add new "features" but just fix bugs for the next 2 weeks -- I'll have all fall for the next bunch of features (including, perhaps, the ones I've been trying to find time to work on).
I'll do my usual compiling and spot testing, hopefully putting out the test versions within the next day.
cheers Miller
Sounds good to me, I should be able to spend a lot of time working on this in the next two weeks. I also set up nightly builds on all the machines from the pure-data.git. I can also get you running on via ssh/VNC/ on the PdLab test machines so you can test wherever you have internet :).
Thanks for accepting all the patches, Pd-extended is going to be reduced to like 5 patches (initbang, font/colorization, string, etc.). I'm curious what features you have in mind, and looking forward to having you in NYC. Perhaps we should have a mini PdCon here in the Fall :)
.hc
On Wed, 2010-08-18 at 17:06 -0700, Miller Puckette wrote:
Hi all,
I have only 2 weeks left in the vicinity of my usual collection of testing machines (will be in New York Sept 1 - Jan. 1!) and so should probably try to get 0.43 finalized. I have several bugs to work on but I think the whole thing is ready to put out compiled "test versions" for people to exercise.
I'll try not to add new "features" but just fix bugs for the next 2 weeks -- I'll have all fall for the next bunch of features (including, perhaps, the ones I've been trying to find time to work on).
I'll do my usual compiling and spot testing, hopefully putting out the test versions within the next day.
cheers Miller
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
--- On Thu, 8/19/10, Hans-Christoph Steiner hans@at.or.at wrote:
From: Hans-Christoph Steiner hans@at.or.at Subject: Re: [PD-dev] run-up to release 0.43 To: "Miller Puckette" msp@ucsd.edu Cc: pd-dev@iem.at Date: Thursday, August 19, 2010, 8:18 PM
Sounds good to me, I should be able to spend a lot of time working on this in the next two weeks. I also set up nightly builds on all the machines from the pure-data.git. I can also get you running on via ssh/VNC/ on the PdLab test machines so you can test wherever you have internet :).
Thanks for accepting all the patches, Pd-extended is going to be reduced to like 5 patches (initbang, font/colorization, string, etc.).
Miller- would you mind commenting on the initbang/closebang patch on Sourceforge, as to why it's still not included in your Pd?
Thanks, Jonathan
I'm curious what features you have in mind, and looking forward to having you in NYC. Perhaps we should have a mini PdCon here in the Fall :)
.hc
On Wed, 2010-08-18 at 17:06 -0700, Miller Puckette wrote:
Hi all,
I have only 2 weeks left in the vicinity of my usual
collection of testing
machines (will be in New York Sept 1 - Jan. 1!) and so
should probably
try to get 0.43 finalized. I have several bugs
to work on but I think the
whole thing is ready to put out compiled "test
versions" for people to
exercise.
I'll try not to add new "features" but just fix bugs
for the next 2 weeks --
I'll have all fall for the next bunch of features
(including, perhaps, the
ones I've been trying to find time to work on).
I'll do my usual compiling and spot testing, hopefully
putting out the
test versions within the next day.
cheers Miller
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi Jonathan -
I don't feel confortable with the design but don't understand the rationale for them well enough to know how to evaluate them. (And I think initbang and closebang are totally different animals...)
I want to redesign loadbang to take arguments, one of which could indicate at what "phase" of loading or closing the message should come out -- but this is a bigger design problem than I'm able to attack right now. I worry, though, that enshrining the proposed initbang/closebang will make thiings uglier and more complicated than necessary.
cheers Miller
Miller- would you mind commenting on the initbang/closebang patch on Sourceforge, as to why it's still not included in your Pd?
Thanks, Jonathan
I'm curious what features you have in mind, and looking forward to having you in NYC. Perhaps we should have a mini PdCon here in the Fall :)
.hc
On Wed, 2010-08-18 at 17:06 -0700, Miller Puckette wrote:
Hi all,
I have only 2 weeks left in the vicinity of my usual
collection of testing
machines (will be in New York Sept 1 - Jan. 1!) and so
should probably
try to get 0.43 finalized. I have several bugs
to work on but I think the
whole thing is ready to put out compiled "test
versions" for people to
exercise.
I'll try not to add new "features" but just fix bugs
for the next 2 weeks --
I'll have all fall for the next bunch of features
(including, perhaps, the
ones I've been trying to find time to work on).
I'll do my usual compiling and spot testing, hopefully
putting out the
test versions within the next day.
cheers Miller
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at
While I can't really comment on the implementation since i haven't reviewed it in depth, I can say that I am a fan of having the interface be a series of *bang objects over having a [loadbang] with arguments. I think its nice, simple, and clear. Then we also can have things like [propertybang] for implementing Properties panels in abstractions.
Also, I've used [initbang] some in Pd-extended and so far it works well. [closebang] is tricky because the patch is being deleted when its triggered.
.hc
On Thu, 2010-08-19 at 13:44 -0700, Miller Puckette wrote:
Hi Jonathan -
I don't feel confortable with the design but don't understand the rationale for them well enough to know how to evaluate them. (And I think initbang and closebang are totally different animals...)
I want to redesign loadbang to take arguments, one of which could indicate at what "phase" of loading or closing the message should come out -- but this is a bigger design problem than I'm able to attack right now. I worry, though, that enshrining the proposed initbang/closebang will make thiings uglier and more complicated than necessary.
cheers Miller
Miller- would you mind commenting on the initbang/closebang patch on Sourceforge, as to why it's still not included in your Pd?
Thanks, Jonathan
I'm curious what features you have in mind, and looking forward to having you in NYC. Perhaps we should have a mini PdCon here in the Fall :)
.hc
On Wed, 2010-08-18 at 17:06 -0700, Miller Puckette wrote:
Hi all,
I have only 2 weeks left in the vicinity of my usual
collection of testing
machines (will be in New York Sept 1 - Jan. 1!) and so
should probably
try to get 0.43 finalized. I have several bugs
to work on but I think the
whole thing is ready to put out compiled "test
versions" for people to
exercise.
I'll try not to add new "features" but just fix bugs
for the next 2 weeks --
I'll have all fall for the next bunch of features
(including, perhaps, the
ones I've been trying to find time to work on).
I'll do my usual compiling and spot testing, hopefully
putting out the
test versions within the next day.
cheers Miller
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 12:37 AM, Hans-Christoph Steiner wrote:
While I can't really comment on the implementation since i haven't reviewed it in depth, I can say that I am a fan of having the interface be a series of *bang objects over having a [loadbang] with arguments. I think its nice, simple, and clear. Then we also can have things like [propertybang] for implementing Properties panels in abstractions.
ahm, what is wrong with the [propertybang] as found in iemguts? and how would the inclusion of [initbang] be related to this?
or is it just a general comment on why you (and me :-)) prefer a number of *bang objects over e.g. [loadbang close]
as for the implementation: i don't care if it was implemented differently. iirc, i tried to follow the implementation style as closely as that of the rest of Pd ;-)
Also, I've used [initbang] some in Pd-extended and so far it works well. [closebang] is tricky because the patch is being deleted when its triggered.
well yes, that's the idea of [closebang], no? i don't really understand what is tricky about it.
mfdsdfg IOhannes
On Aug 20, 2010, at 5:42 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 12:37 AM, Hans-Christoph Steiner wrote:
While I can't really comment on the implementation since i haven't reviewed it in depth, I can say that I am a fan of having the interface be a series of *bang objects over having a [loadbang] with arguments. I think its nice, simple, and clear. Then we also can have things like [propertybang] for implementing Properties panels in abstractions.
ahm, what is wrong with the [propertybang] as found in iemguts? and how would the inclusion of [initbang] be related to this?
or is it just a general comment on why you (and me :-)) prefer a number of *bang objects over e.g. [loadbang close]
as for the implementation: i don't care if it was implemented differently. iirc, i tried to follow the implementation style as closely as that of the rest of Pd ;-)
I'm saying I like the interface of having a suite of objects called *bang rather than [loadbang close], etc. it makes them super easy to use and remember.
[initbang] [loadbang] [propertybang] [closebang]
Also, I've used [initbang] some in Pd-extended and so far it works well. [closebang] is tricky because the patch is being deleted when its triggered.
well yes, that's the idea of [closebang], no? i don't really understand what is tricky about it.
Well, it doesn't really seem to work. Or at least the [closebang] in Pd-extended doesn't seem to ever output the bang.
.hc
mfdsdfg IOhannes
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxuTf0ACgkQkX2Xpv6ydvSQPACeMDNF4W9d/HZ185nYXePNzG5J QmsAoKAjmfYdF4G/36w/Sch6vsB01YKU =3f+6 -----END PGP SIGNATURE-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 08:02 PM, Hans-Christoph Steiner wrote:
well yes, that's the idea of [closebang], no? i don't really understand what is tricky about it.
Well, it doesn't really seem to work. Or at least the [closebang] in Pd-extended doesn't seem to ever output the bang.
interesting.
the attached abstraction works for me (on a vanilla Pd-0.42.5 with only the closebang/initbang patches applied).
mfgasdr IOhannes
On Aug 20, 2010, at 2:56 PM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/20/2010 08:02 PM, Hans-Christoph Steiner wrote:
well yes, that's the idea of [closebang], no? i don't really understand what is tricky about it.
Well, it doesn't really seem to work. Or at least the [closebang] in Pd-extended doesn't seem to ever output the bang.
interesting.
the attached abstraction works for me (on a vanilla Pd-0.42.5 with only the closebang/initbang patches applied).
Oops, I should respond here. After our chat on #dataflow, how do you want to go about with the rename of closebang to destroybang? That will make it much more self-documenting since silly people like me won't assume its about closing windows.
.hc
----------------------------------------------------------------------------
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Hi,
On Fri, Aug 20, 2010 at 02:02:08PM -0400, Hans-Christoph Steiner wrote:
On Aug 20, 2010, at 5:42 AM, IOhannes m zmölnig wrote: I'm saying I like the interface of having a suite of objects called *bang rather than [loadbang close], etc. it makes them super easy to use and remember.
[initbang] [loadbang] [propertybang] [closebang]
The only issue I have with this is the difference between initbang and loadbang. In several patches posted to this list in the past I observed, that sometimes people tended to use initbang where a simple loadbang would be sufficient, i.e. they were doing nothing that would actually require initbang.(*) I assume this is because they actually didn't know or understand the difference.
That's where a loadbang object that somehow combined initbang into it with an argument *may* be preferable. I don't see any reason to combine load- and closebang (or propertybang, but I don't really know that. I assume it will fire when Help->Properties is selected.)
(*) A typical example were abstractions using initbang because their loadbang would not fire after dynamic patching. Here initbang is not the correct solution, but a "loadbang"-message to the dynamic patching canvas.
Ciao
On Aug 21, 2010, at 3:47 AM, Frank Barknecht wrote:
Hi,
On Fri, Aug 20, 2010 at 02:02:08PM -0400, Hans-Christoph Steiner wrote:
On Aug 20, 2010, at 5:42 AM, IOhannes m zmölnig wrote: I'm saying I like the interface of having a suite of objects called *bang rather than [loadbang close], etc. it makes them super easy to use and remember.
[initbang] [loadbang] [propertybang] [closebang]
The only issue I have with this is the difference between initbang and loadbang. In several patches posted to this list in the past I observed, that sometimes people tended to use initbang where a simple loadbang would be sufficient, i.e. they were doing nothing that would actually require initbang.(*) I assume this is because they actually didn't know or understand the difference.
That's where a loadbang object that somehow combined initbang into it with an argument *may* be preferable. I don't see any reason to combine load- and closebang (or propertybang, but I don't really know that. I assume it will fire when Help->Properties is selected.)
(*) A typical example were abstractions using initbang because their loadbang would not fire after dynamic patching. Here initbang is not the correct solution, but a "loadbang"-message to the dynamic patching canvas.
Yeah, we definitely don't want [initbang] to be used too often, I can understand that. I just differ with how we should deal with the problem. I think it should be handled in the documentation rather than making the programming part more complicated.
I could see the initbang help path having a section called "When to NOT use initbang" then it would include your example below with the example of how to use it. The initbang help patch is in a pretty sorry state right now... its in SVN doc/pddp if anyone wants to take it on.
.hc
----------------------------------------------------------------------------
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
On 2010-08-23 17:33, Hans-Christoph Steiner wrote:
Yeah, we definitely don't want [initbang] to be used too often, I can
i would also like to state, that we shouldn't use [metro] too often. reversely, one cannot use [trigger] too often. so Pd should print out a warning if there is no [t] in the patch whenever it is saved.
understand that. I just differ with how we should deal with the problem. I think it should be handled in the documentation rather than making the programming part more complicated.
seriously, i don't see so many drawbacks with [initbang]. the biggest issue right now, is that there is no [initbang] in Pd-vanilla. this makes patches using [initbang] incompatible with Pd-vanilla. once it was included, this issue would become nought.
I could see the initbang help path having a section called "When to NOT use initbang" then it would include your example below with the example of how to use it.
hmm, i guess some words are missing here, as i don't understand why we would include an example of how to use it in the "when to NOT use it" section.
anyhow, in most cases [initbang] can be used as a replacement for [loadbang]. the only difference is, that [initbang] will not make it to the outside of the patch using [outlet]s.
so you cannot use [initbang] to initialize the parent patch. darn, bad naming again. probably [createbang] would be better (esp. if [closebang] is renamed to [destroybang]) or use [constructorbang] and [destructorbang]
anyhow, whatever the name of the object (even [loadbang really-early]), th changes to the c-sources will be very similar.
The initbang help patch is in a pretty sorry state right now... its in SVN doc/pddp if anyone wants to take it on.
probably we should wait whether this evolves before documenting things to be abandoned.
fgmasdr IOhannes
--- On Mon, 8/23/10, IOhannes m zmoelnig zmoelnig@iem.at wrote:
From: IOhannes m zmoelnig zmoelnig@iem.at Subject: Re: [PD-dev] initbang and friends WAS: run-up to release 0.43 To: pd-dev@iem.at Date: Monday, August 23, 2010, 6:07 PM On 2010-08-23 17:33, Hans-Christoph Steiner wrote:
Yeah, we definitely don't want [initbang] to be used
too often, I can
i would also like to state, that we shouldn't use [metro] too often. reversely, one cannot use [trigger] too often. so Pd should print out a warning if there is no [t] in the patch whenever it is saved.
understand that. I just differ with how we
should deal with the
problem. I think it should be handled in the
documentation rather than
making the programming part more complicated.
seriously, i don't see so many drawbacks with [initbang]. the biggest issue right now, is that there is no [initbang] in Pd-vanilla. this makes patches using [initbang] incompatible with Pd-vanilla. once it was included, this issue would become nought.
I agree that is the overriding issue.
I could see the initbang help path having a section
called "When to NOT
use initbang" then it would include your example below
with the example
of how to use it.
hmm, i guess some words are missing here, as i don't understand why we would include an example of how to use it in the "when to NOT use it" section.
I've revised the [initbang] help patch to include an example with dynamically creating an outlet. But after reading about your use of [initbang] in realtime patching, I just need to change the wording a little to make it clear that it's not the _only_ use for [initbang]
Btw-- in your live-coding example you mentioned you were sending the audio to a bus and would use [initbang] to fade in. But how do you use [closebang] to fade out? Does [closebang] send a trigger to one of the sister abstractions to do the fade out?
anyhow, in most cases [initbang] can be used as a replacement for [loadbang]. the only difference is, that [initbang] will not make it to the outside of the patch using [outlet]s.
Right-- in that case you would use Frank's method. Although in an oscillator bank patch I made, sending a "loadbang" message crashed Pd. I changed it to [r $1-loadbang] as a workaround, but I never went back and hunted down the original problem.
so you cannot use [initbang] to initialize the parent patch. darn, bad naming again. probably [createbang] would be better (esp. if [closebang] is renamed to [destroybang]) or use [constructorbang] and [destructorbang]
anyhow, whatever the name of the object (even [loadbang really-early]), th changes to the c-sources will be very similar.
[preloadbang]
The initbang help patch is in a pretty sorry state right now... its in SVN doc/pddp if anyone wants
to take it on.
probably we should wait whether this evolves before documenting things to be abandoned.
I'd rather risk irrelevant documentation in 2025 than have shoddy documentation right now.
-Jonathan
fgmasdr IOhannes
-----Inline Attachment Follows-----
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 2010-08-23 19:10, Jonathan Wilkes wrote:
Btw-- in your live-coding example you mentioned you were sending the audio to a bus and would use [initbang] to fade in. But how do you use [closebang] to fade out? Does [closebang] send a trigger to one of the sister abstractions to do the fade out?
right. on creation of the bus-sender, i dynamically create a proxy bus-receiver abstraction that receives the signal, does a fade in, delays the signal by a certain amount and adds it to the real summing bus. once the bus-sender get's destroyed it notifies the proxy receiver that the signal is going to vanish, and the proxy does a fade out (it has some time left, as it has delayed the signal) and then destroys itself.
Right-- in that case you would use Frank's method. Although in an oscillator bank patch I made, sending a "loadbang" message
this really depends on the original problem. in many cases it is enough to just re-trigger the loadbang (with the "loadbang" message). in other cases it is not enough. e.g. when you don't create all instances of your oscillator bank in zero logical time, but as they are needed. then you often don't want loadbangS to re-fire. this of course can easily be fixed by creating a [loadbangonce] abstraction.
but just because you can already solve some issues with the current mechanisms, doesn't mean that they can't be improved (esp. when the improvement makes things possible that are currently impossible)
crashed Pd. I changed it to [r $1-loadbang] as a workaround, but I never went back and hunted down the original problem.
which is a pity, as now there is only the rumour of a bug, which is way worse than a real bug (fixing a rumour proves harder than fixing a bug)
so you cannot use [initbang] to initialize the parent patch. darn, bad naming again. probably [createbang] would be better (esp. if [closebang] is renamed to [destroybang]) or use [constructorbang] and [destructorbang]
anyhow, whatever the name of the object (even [loadbang really-early]), th changes to the c-sources will be very similar.
[preloadbang]
as a matter of fact, i think [loadbang] has a bad naming as well.
sdf IOhannes
On Aug 23, 2010, at 12:07 PM, IOhannes m zmoelnig wrote:
On 2010-08-23 17:33, Hans-Christoph Steiner wrote:
Yeah, we definitely don't want [initbang] to be used too often, I can
i would also like to state, that we shouldn't use [metro] too often. reversely, one cannot use [trigger] too often. so Pd should print out a warning if there is no [t] in the patch whenever it is saved.
understand that. I just differ with how we should deal with the problem. I think it should be handled in the documentation rather than making the programming part more complicated.
seriously, i don't see so many drawbacks with [initbang]. the biggest issue right now, is that there is no [initbang] in Pd- vanilla. this makes patches using [initbang] incompatible with Pd-vanilla. once it was included, this issue would become nought.
I could see the initbang help path having a section called "When to NOT use initbang" then it would include your example below with the example of how to use it.
hmm, i guess some words are missing here, as i don't understand why we would include an example of how to use it in the "when to NOT use it" section.
anyhow, in most cases [initbang] can be used as a replacement for [loadbang]. the only difference is, that [initbang] will not make it to the outside of the patch using [outlet]s.
so you cannot use [initbang] to initialize the parent patch. darn, bad naming again. probably [createbang] would be better (esp. if [closebang] is renamed to [destroybang]) or use [constructorbang] and [destructorbang]
[createbang] and [destroybang] is a nice pair. :)
.hc
anyhow, whatever the name of the object (even [loadbang really- early]), th changes to the c-sources will be very similar.
The initbang help patch is in a pretty sorry state right now... its in SVN doc/pddp if anyone wants to take it on.
probably we should wait whether this evolves before documenting things to be abandoned.
fgmasdr IOhannes
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
so you cannot use [initbang] to initialize the parent patch. darn, bad naming again. probably [createbang] would be better (esp. if [closebang] is renamed to [destroybang]) or use [constructorbang] and [destructorbang]
[createbang] and [destroybang] is a nice pair. :)
.hc
But then we'd need [evolvebang] and [extinctbang] ...
On Tue, Aug 24, 2010 at 12:40:59AM -0400, Matt Barber wrote:
[createbang] and [destroybang] is a nice pair. :) .hc
But then we'd need [evolvebang] and [extinctbang] ...
Unless you patches are intelligently designed. :)
Ciao
On 2010-08-24 05:39, Hans-Christoph Steiner wrote:
or use [constructorbang] and [destructorbang]
[createbang] and [destroybang] is a nice pair. :)
yes, but they have 2 drawbacks:
- the seem to be "actors" rather than "reactors"; e.g. i would expect [destroybang] to destroy something, rather than tell me when things are destroyed. (btw, [loadbang] has the same issue)
- they invent different names for things already well established and baptized in the computer science, namely "constructor" and "destructor". this adds confusion for people that already know the concept, and doesn't help people that don't know the concepts yet (and i firmly believe that we shouldn't take patchers for fools - regardless of whether we want to be pedagogical or not)
the main pro is, that the names are shorter.
mfgsdf IOhannes
On Aug 24, 2010, at 3:04 AM, IOhannes m zmoelnig wrote:
On 2010-08-24 05:39, Hans-Christoph Steiner wrote:
or use [constructorbang] and [destructorbang]
[createbang] and [destroybang] is a nice pair. :)
yes, but they have 2 drawbacks:
- the seem to be "actors" rather than "reactors"; e.g. i would expect
[destroybang] to destroy something, rather than tell me when things are destroyed. (btw, [loadbang] has the same issue)
If you know what a bang means, I think its quite clear that these produce bangs related to "load", "create", etc.
- they invent different names for things already well established and
baptized in the computer science, namely "constructor" and "destructor". this adds confusion for people that already know the concept, and doesn't help people that don't know the concepts yet (and i firmly believe that we shouldn't take patchers for fools - regardless of whether we want to be pedagogical or not)
the main pro is, that the names are shorter.
But Pd was created as a reaction against the overcomplicatedness of computer science, and those words are a perfect example of it. CS does not have bang, abstractions, patches, etc. yet somehow we communicate ;) Pd does not have constructors and destructors, tho the implementation might sometimes.
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
Hi,
On Wed, Aug 18, 2010 at 05:06:44PM -0700, Miller Puckette wrote:
I'll try not to add new "features" but just fix bugs for the next 2 weeks
There is one bugfix I wish to have for a long time: make [wrap~] output 0 when it receives [sig~ 0]. I don't think, anyone really relied on the wrong 1, that wrap~ currently produces, so this backwards incompatible change would be resonable IMO.
My other wish is a feature: [tabpoke~]/[tabwriteat~]??? :)
Ciao
On 08/19/2010 02:06 AM, Miller Puckette wrote:
I'll try not to add new "features" but just fix bugs for the next 2 weeks --
here is one bug (+ fix): "pd -version" prints garbage.
https://sourceforge.net/tracker/?func=detail&aid=3050371&group_id=55...
mgfasdr IOhannes
On 08/21/2010 06:32 PM, IOhannes zmölnig wrote:
On 08/19/2010 02:06 AM, Miller Puckette wrote:
I'll try not to add new "features" but just fix bugs for the next 2 weeks --
here is one bug
and of course there are several simple bugfixes still pending in the tracker:
e.g. 2806049: [bugfix] renamed arrays do not get used by dsp 2835752: floor, ceil functions in expr misdeclared
those are really simple, about 2 lines code each.
gmasdr IOhannes
hello,
i've got a new problem with this test version. yesterday, i add -font-face "andale mono" in pd startup preference. now, when i try to open this preference dialog, i have this error :
(Tcl) UNHANDLED ERROR: extra characters after close-quote while executing "pdtk_startup_dialog .gfxstuba0f0fd0 0 "-listdev -mididev 1,2,3,4 -font-face "andale mono" -noautopatch -rt -alsa -alsaadd default -audiooutdev 3" " ("uplevel" body line 5) invoked from within "uplevel #0 $cmd_from_pd"
cheers cyrille
Le 19/08/2010 02:06, Miller Puckette a écrit :
Hi all,
I have only 2 weeks left in the vicinity of my usual collection of testing machines (will be in New York Sept 1 - Jan. 1!) and so should probably try to get 0.43 finalized. I have several bugs to work on but I think the whole thing is ready to put out compiled "test versions" for people to exercise.
I'll try not to add new "features" but just fix bugs for the next 2 weeks -- I'll have all fall for the next bunch of features (including, perhaps, the ones I've been trying to find time to work on).
I'll do my usual compiling and spot testing, hopefully putting out the test versions within the next day.
cheers Miller
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
That's a bug in the command line flag parsing, you should file a bug report. IMHO, the whole flag parser should be rewritten using on of the standard opt/flag parsing libraries. getopt is in libc but is more limited, I am sure there is a GNU parser that handles -s short and --long options well.
.hc
On Thu, 2010-08-26 at 12:34 +0200, cyrille henry wrote:
hello,
i've got a new problem with this test version. yesterday, i add -font-face "andale mono" in pd startup preference. now, when i try to open this preference dialog, i have this error :
(Tcl) UNHANDLED ERROR: extra characters after close-quote while executing "pdtk_startup_dialog .gfxstuba0f0fd0 0 "-listdev -mididev 1,2,3,4 -font-face "andale mono" -noautopatch -rt -alsa -alsaadd default -audiooutdev 3" " ("uplevel" body line 5) invoked from within "uplevel #0 $cmd_from_pd"
cheers cyrille
Le 19/08/2010 02:06, Miller Puckette a écrit :
Hi all,
I have only 2 weeks left in the vicinity of my usual collection of testing machines (will be in New York Sept 1 - Jan. 1!) and so should probably try to get 0.43 finalized. I have several bugs to work on but I think the whole thing is ready to put out compiled "test versions" for people to exercise.
I'll try not to add new "features" but just fix bugs for the next 2 weeks -- I'll have all fall for the next bunch of features (including, perhaps, the ones I've been trying to find time to work on).
I'll do my usual compiling and spot testing, hopefully putting out the test versions within the next day.
cheers Miller
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, Aug 31, 2010 at 4:02 AM, Hans-Christoph Steiner hans@at.or.atwrote:
That's a bug in the command line flag parsing, you should file a bug report. IMHO, the whole flag parser should be rewritten using on of the standard opt/flag parsing libraries. getopt is in libc but is more limited, I am sure there is a GNU parser that handles -s short and --long options well.
http://sourceforge.net/projects/argopt/ (inactive project, wonder if it's usable yet) http://directory.fsf.org/project/popt/ (x11 licence) i don't know is this is serious enough: http://wiki.tcl.tk/22050
Andras
On Tue, 2010-08-31 at 22:04 +0200, András Murányi wrote:
On Tue, Aug 31, 2010 at 4:02 AM, Hans-Christoph Steiner hans@at.or.at wrote:
That's a bug in the command line flag parsing, you should file a bug report. IMHO, the whole flag parser should be rewritten using on of the standard opt/flag parsing libraries. getopt is in libc but is more limited, I am sure there is a GNU parser that handles -s short and --long options well.http://sourceforge.net/projects/argopt/ (inactive project, wonder if it's usable yet) http://directory.fsf.org/project/popt/ (x11 licence) i don't know is this is serious enough: http://wiki.tcl.tk/22050
Well, we'd want it to be something that is already widely deployed, like something in GNU libc or POSIX. popt looks pretty well used, at least on Debian/Ubuntu, but I think getopt() and getopt_long() are just about everywhere by default now.
.hc
-
András Murányi -
cyrille henry -
Frank Barknecht -
glerm soares -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
IOhannes zmölnig
-
Jonathan Wilkes -
Matt Barber -
Miller Puckette