The nightly builds are on a separate server:
http://autobuild.puredata.info/auto-build/
.hc
On Tue, 2011-09-13 at 16:54 +0000, Marc D. Demers wrote:
> Hi Hans,
>
> I will be glad to tried out the new PD-extended version but I've been
> unable to connect to the PD site for the past three days... The link
> seems broken...
>
> Regards,
>
> Marc
>
>
>
>
>
> > From: hans(a)at.or.at
> > To: pd-dev(a)iem.at
> > Date: Tue, 13 Sep 2011 12:06:45 -0400
> > Subject: [PD-dev] pd-extended 0.43 release push
> >
> >
> > I was thinking that now would be a good time to start a release
> cycle
> > for Pd-extended 0.43. There is a ton of really useful new stuff in
> the
> > editor with the new gui, plugins, etc. So I'm thinking I'll delay
> some
> > of the library work I've been doing, and revert to the 0.42.5
> behavior
> > of loading a bunch of libraries by default at startup. But I
> personally
> > be dropping my support for a number of included libraries, but
> anyone is
> > welcome to pick them up if they want to see them stay in
> Pd-extended.
> > You can see the state of things here:
> >
> > http://puredata.info/docs/LibrariesInPdExtended
> >
> > This can be a trial run of the new process of keeping things in
> > Pd-extended. Basically, I need to reduce my maintenance load, I just
> > can't keep up any more. So I am proposing that the new process for
> > getting things into a Pd-extended release. First, the new release
> > branch will be a copy of the previous release branch. Each
> library/doc
> > has a maintainer, listed on the LibrariesInPdExtended page. It is
> that
> > maintainer's job to update their libraries/docs into the pd-extended
> > release branch, otherwise the version will be the same as the
> previous
> > version. Each version of a library included in Pd-extended needs to
> a
> > fully released version with a proper version number and a release
> posted
> > on its own page in the http://puredata.info/downloads section, and
> > ultimately uploaded to Debian/testing (I'm happy to sponsor people's
> > packages for upload to Debian once they are ready). The full process
> is
> > documented here:
> >
> > http://puredata.info/docs/developer/GettingIntoPdextended
> >
> > Comments, feedback, concerns? I'd like to make this a much more open
> > and participatory process.
> >
> > .hc
> >
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev(a)iem.at
> > http://lists.puredata.info/listinfo/pd-dev
>
Bugs item #3408113, was opened at 2011-09-12 15:07
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3408113&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Block-Sync-Bug!!
Initial Comment:
Hello, I just wanted to inform you guys about this thread in the Pd-Forum ( http://puredata.hurleur.com/sujet-6171-block-bug-sync-differently-sized-blo… ) !!
There is a patch attached (login to see it) (...I have upoloaded it here, too..) that describes the buggy situation.
Summary:Main-patch(block~ 64 1 1; syncable phasor~) + "Sub-sub-patch"(block~ 64 1 1; syncable phasor~) is in a subpatch(block~ 32 1 1) . Sometimes sync works, sometimes not (maybe depending on the blocksize-quotient), and by sometimes I don't mean individual sync-attempts but rather after adding even just a text to the patch, by changing a connection or by switching the dsp off and on!!
Please let us know if there is a workaround or what you think in general.
Im on windows and I used pd-0.42.5-ext & pd-0.43.
Thx
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3408113&group_…
I have 2 large equations that I would like to create an external for. One
of the 2 equations http://dl.dropbox.com/u/6576402/questions/eq1.txt
Basically it's a 1 second periodic signal with sample rate at 44100 which
the equation gives me control over the frequency,amplitude,phase and
vertical offset
So my logic is to have 4 inlets for the frequency,amplitude,phase and
vertical offset and an output for the signal.
If you want to know what type of PD I'm creating and it's options.
1) The first option will import a text file into a table/array that will
control the variables of the equations that will vary
frequency,amplitude,phase and vertical offset over time.
2) The second option will allow the variables to be controllable/variable
using a midi controller and it's audio signal played
I've been able to find instructions on how to create a hello world
C-external but not one that creates a simple sine wave from a sinewave
equation like A*sin(w*t+p)
(https://secure.wikimedia.org/wikipedia/en/wiki/Sine_wave) Does anyone have
one or know where to find one.
It makes sense to make a C external and create inputs for the values of
frequency,amplitude,phase and vertical offset.
That way I can cleanly feed/control those values with a midi controller or a
table/array in PureData.
Thanks
--
--
Bugs item #3406973, was opened at 2011-09-09 18:04
Message generated for change (Tracker Item Submitted) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3406973&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: externals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: IOhannes m zmölnig (zmoelnig)
Summary: zexy/unpack doesn't handle multi-symbol messages like unpack
Initial Comment:
If you send a message like [one two three four( to [zexy/unpack], you get "zexy/unpack: no method for 'one'", but Pd's [unpack] outputs it fine. Attached is a patch that illustrates the bug.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3406973&group_…
Bugs item #3402940, was opened at 2011-09-01 23:25
Message generated for change (Tracker Item Submitted) made by vilsonvieira
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3402940&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: pd-extended
Group: v0.42
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vilson Vieira (vilsonvieira)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: Missing iemmatrix on Ubuntu 11.04
Initial Comment:
I'm using Ubuntu GNU/Linux 11.04 with Pd installed from a latest build .deb (it is confirmed on other machine running Ubuntu 11.04 too).
The iemmatrix is missing from /usr/lib/pd-extended/iemmatrix.
I've compiled and installed iemmatrix from the Pd SVN [1] and added /usr/lib/pd-extended/iemmatrix on Pd's File -> Path... and it worked.
[1] svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/externals/iem…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=3402940&group_…
Patches item #3400300, was opened at 2011-08-29 15:08
Message generated for change (Comment added) made by jancsika1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: feature
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: move cord drawing from pd to Tcl procs in pd-gui
Initial Comment:
This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-08-31 18:21
Message:
Right-- when I said "drawing instructions" I really just meant where the
line begins and ends. I can't see a case where this would be different
between signal and control cords.
Still, I wouldn't hard code values for the various options in those procs.
Use variables.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-08-31 12:57
Message:
(oops that was me not logged in)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-08-31 12:57
Message:
You just answered your question :) The line width is one difference
between signal and message cords. Another would be to have different
colors, different line ending treatments, different patterns, etc. Some
people might want to make Pd look like Max/MSP for example, and that has
weird stripey cords. Another reason to have the signal/message conditional
in C is speed. It'll execute much faster there.
And really, I don't see the difference between adding a proc and adding
another block in a if/then/else statement. Both are very straightforward
and easy.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-08-31 01:59
Message:
Oops, I guess "drawing instructions" is an ambiguous term. I just mean the
coordinates: startx/y and endx/y. All the other options could be done with
a conditional.
BTW-- any reason you are hardcoding a width of "2" in that proc?
Shouldn't it be something like -width $::signalcordwidth, with
::signalcordwidth being defined in pd-gui.tcl? (Could also use the options
database but that's probably overkill.)
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-08-30 23:23
Message:
I think you just need one proc with an arg corresponding to control/signal.
All customization can be done elsewhere by referring to the tags. I can't
think of any divergences between messagecord (controlcord?) and signalcord
that would require different initial drawing instructions; all future
features I can think of-- segmented cords or new cord
selection/deletion/edition-- would be handled identically for both cases,
no? If you disagree, could you give an example of a way in which a
signalcord would ever require different drawing instructions than a
controlwire?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-08-30 12:36
Message:
I think having separate procs/messages for each connection type makes it
easier to customize. And its just as easy to add a proc for any new
connection type as it is to add a block to a switch or something like that.
Given that no new connection types have been added to Pd since its
inception, I don't think its a high priority concern.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-08-30 03:09
Message:
i haven't had a look yet, but wouldn't it be better to use a single
tcl-proc "connect" (or "draw_cords") and specify the type of connection as
an argument?
this way it can be more easily expanded to other connection types.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…
Patches item #3400300, was opened at 2011-08-29 15:08
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: feature
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: move cord drawing from pd to Tcl procs in pd-gui
Initial Comment:
This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-08-31 12:57
Message:
(oops that was me not logged in)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-08-31 12:57
Message:
You just answered your question :) The line width is one difference
between signal and message cords. Another would be to have different
colors, different line ending treatments, different patterns, etc. Some
people might want to make Pd look like Max/MSP for example, and that has
weird stripey cords. Another reason to have the signal/message conditional
in C is speed. It'll execute much faster there.
And really, I don't see the difference between adding a proc and adding
another block in a if/then/else statement. Both are very straightforward
and easy.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-08-31 01:59
Message:
Oops, I guess "drawing instructions" is an ambiguous term. I just mean the
coordinates: startx/y and endx/y. All the other options could be done with
a conditional.
BTW-- any reason you are hardcoding a width of "2" in that proc?
Shouldn't it be something like -width $::signalcordwidth, with
::signalcordwidth being defined in pd-gui.tcl? (Could also use the options
database but that's probably overkill.)
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-08-30 23:23
Message:
I think you just need one proc with an arg corresponding to control/signal.
All customization can be done elsewhere by referring to the tags. I can't
think of any divergences between messagecord (controlcord?) and signalcord
that would require different initial drawing instructions; all future
features I can think of-- segmented cords or new cord
selection/deletion/edition-- would be handled identically for both cases,
no? If you disagree, could you give an example of a way in which a
signalcord would ever require different drawing instructions than a
controlwire?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-08-30 12:36
Message:
I think having separate procs/messages for each connection type makes it
easier to customize. And its just as easy to add a proc for any new
connection type as it is to add a block to a switch or something like that.
Given that no new connection types have been added to Pd since its
inception, I don't think its a high priority concern.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-08-30 03:09
Message:
i haven't had a look yet, but wouldn't it be better to use a single
tcl-proc "connect" (or "draw_cords") and specify the type of connection as
an argument?
this way it can be more easily expanded to other connection types.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…
Patches item #3400300, was opened at 2011-08-29 19:08
Message generated for change (Comment added) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: feature
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Miller Puckette (millerpuckette)
Summary: move cord drawing from pd to Tcl procs in pd-gui
Initial Comment:
This patch replaces the raw Tcl code in the 'pd' process' C code with two Tcl procs in pdtk_canvas: draw_signal_cord and draw_message_cord. This allows for customization of the cords from GUI plugins and Pd patches. This also is a step in the direction of making the 'pd' --> 'pd-gui' communications Pd messages rather than Tcl code.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2011-08-31 16:57
Message:
You just answered your question :) The line width is one difference
between signal and message cords. Another would be to have different
colors, different line ending treatments, different patterns, etc. Some
people might want to make Pd look like Max/MSP for example, and that has
weird stripey cords. Another reason to have the signal/message conditional
in C is speed. It'll execute much faster there.
And really, I don't see the difference between adding a proc and adding
another block in a if/then/else statement. Both are very straightforward
and easy.
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-08-31 05:59
Message:
Oops, I guess "drawing instructions" is an ambiguous term. I just mean the
coordinates: startx/y and endx/y. All the other options could be done with
a conditional.
BTW-- any reason you are hardcoding a width of "2" in that proc?
Shouldn't it be something like -width $::signalcordwidth, with
::signalcordwidth being defined in pd-gui.tcl? (Could also use the options
database but that's probably overkill.)
----------------------------------------------------------------------
Comment By: Jonathan Wilkes (jancsika1)
Date: 2011-08-31 03:23
Message:
I think you just need one proc with an arg corresponding to control/signal.
All customization can be done elsewhere by referring to the tags. I can't
think of any divergences between messagecord (controlcord?) and signalcord
that would require different initial drawing instructions; all future
features I can think of-- segmented cords or new cord
selection/deletion/edition-- would be handled identically for both cases,
no? If you disagree, could you give an example of a way in which a
signalcord would ever require different drawing instructions than a
controlwire?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-08-30 16:36
Message:
I think having separate procs/messages for each connection type makes it
easier to customize. And its just as easy to add a proc for any new
connection type as it is to add a block to a switch or something like that.
Given that no new connection types have been added to Pd since its
inception, I don't think its a high priority concern.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2011-08-30 07:09
Message:
i haven't had a look yet, but wouldn't it be better to use a single
tcl-proc "connect" (or "draw_cords") and specify the type of connection as
an argument?
this way it can be more easily expanded to other connection types.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3400300&group_…