Hi all,
Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
Main change from 0.43-2 is that MIDI input is improved on Mac and Windows.
Also, I added a stub to future-proof Pd against a possible extension of the file format so that in the future there could be a way to set widths of boxes and stuff like that (and 0.43-3 would read those files and only complain once instead of complaining for pages.)
I'm ready to start hacking on 0.44. The most urgent thing seems to be for me to go back and work on the audio system (and perhaps tweak MIDI a bit more too).
The thing I'm actually looking forward to doing is to extend textfiles and message boxes and data structures to be able to spit lists of atoms around much more flexibly than now.
Also pd vanilla needs tilde objects to do interpolating signal snapshots, phase-syncable oscillators, and other stuff on that level, also likely to be a lot of fun.
cheers Miller
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
On 07/04/2012 05:11 AM, Miller Puckette wrote:
The thing I'm actually looking forward to doing is to extend textfiles and message boxes and data structures to be able to spit lists of atoms around much more flexibly than now.
Also pd vanilla needs tilde objects to do interpolating signal snapshots, phase-syncable oscillators, and other stuff on that level, also likely to be a lot of fun.
Sounds awesome, I am excited!
Chris.
Hi Miller
On Tue, 2012-07-03 at 14:11 -0700, Miller Puckette wrote:
Hi all,
Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
As always: Many thanks for your efforts!
I'm ready to start hacking on 0.44. The most urgent thing seems to be for me to go back and work on the audio system (and perhaps tweak MIDI a bit more too).
May I ask, what is planned for the audio system, respectively what part needs some work?
My two cents regarding audio: 0.43 introduced a regression (at least on linux, don't know about other OS') in that the behavior was changed so that whenever DSP is turned on, a thread is started, and is stopped again, when DSP is turned off. The implications I experience with this architecture, is that sometimes audio doesn't come back when turning DSP on. Specifically, with the jack backend it sometimes happens, that Pd freezes and I have to restart Pd. With ALSA, when turning DSP off and on again, I sometimes get this error:
snd_pcm_open (output): Device or resource busy
and obviously sound is lost. Usually it helps to turn DSP off and on again to make sound work again. While this is only slightly problematic (though still annoying) in a live situation, it is quite dangerous for installation setups. This could potentially lead to running an installation without sound for the rest of the day.
Keeping the thread talking to the audio back end always running has some advantages:
- The audio card cannot be stolen by other softwares while DSP is off
- A cycle of turning DSP off and on is much faster, since no thread needs to be stopped and started
- less prone to re-connect failures as the back-end stays always connected
- A DSP off-on cycle can be used to increase the speed of dynamic loading of tilde objects / abstractions (now such a cycle is always slow and prone to loosing audio)
I'm also interested to hear if others experience similar issues or if it is only me having trouble with 0.43's design. Up to 0.42 everything was fine for me regarding audio.
The thing I'm actually looking forward to doing is to extend textfiles and message boxes and data structures to be able to spit lists of atoms around much more flexibly than now.
Sounds good.
Also pd vanilla needs tilde objects to do interpolating signal snapshots, phase-syncable oscillators,
What does phase-syncable mean? Do you mean, that the phase for [osc~] and [phasor~] will be settable not only on block-boundaries, but also during a block?
Roman
Quoth Roman Haefeli, on 04/07/2012 12:14:
I'm also interested to hear if others experience similar issues or if it is only me having trouble with 0.43's design. Up to 0.42 everything was fine for me regarding audio.
This may be related:
I just installed pd-extended 0.43.1 on Ubuntu 12.04 and I can't get audio to work in -nogui mode. The usual trick of delaying a loadbang by 1000ms or more results in a high tone, and there is no adc input, so I'm running it in gui mode which works.
James
I posted a patch for this a while ago but I don't think it got incorporated upstream:
http://lists.puredata.info/pipermail/pd-dev/2012-04/018365.html
Chrissie
On 04/07/2012 12:56, James Dunn wrote:
Quoth Roman Haefeli, on 04/07/2012 12:14:
I'm also interested to hear if others experience similar issues or if it is only me having trouble with 0.43's design. Up to 0.42 everything was fine for me regarding audio.
This may be related:
I just installed pd-extended 0.43.1 on Ubuntu 12.04 and I can't get audio to work in -nogui mode. The usual trick of delaying a loadbang by 1000ms or more results in a high tone, and there is no adc input, so I'm running it in gui mode which works.
James
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Its included now but in 0.44: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data;a=...
I included it in Pd-extended 0.43.4 also.
.hc
On Jul 4, 2012, at 8:58 AM, Chrissie Caulfield wrote:
I posted a patch for this a while ago but I don't think it got incorporated upstream:
http://lists.puredata.info/pipermail/pd-dev/2012-04/018365.html
Chrissie
On 04/07/2012 12:56, James Dunn wrote:
This may be related:
I just installed pd-extended 0.43.1 on Ubuntu 12.04 and I can't get audio to work in -nogui mode. The usual trick of delaying a loadbang by 1000ms or more results in a high tone, and there is no adc input, so I'm running it in gui mode which works.
James
Quoth Roman Haefeli, on 04/07/2012 12:14:
I'm also interested to hear if others experience similar issues or if it is only me having trouble with 0.43's design. Up to 0.42 everything was fine for me regarding audio.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-04 13:14, Roman Haefeli wrote:
Keeping the thread talking to the audio back end always running has some advantages:
- The audio card cannot be stolen by other softwares while DSP is
off * A cycle of turning DSP off and on is much faster, since no thread needs to be stopped and started
otoh, releasing the audio backend, allows other software to steal the audio card. i think this is a feature not a bug.
- less prone to re-connect failures as the back-end stays always
connected
instead, i think that re-connects should not fail instead.
- A DSP off-on cycle can be used to increase the speed of dynamic
loading of tilde objects / abstractions (now such a cycle is always slow and prone to loosing audio)
true.
i think that Pd should definitely have a method to release the audio card. currently it is really complicated to start Pd in ALSA, then starting jack outside of Pd and then connect Pd to this instance of jack.
probably a "dummy" audio-backend would help here: this would allow to separate the DSP on/off functionality from the audio-backends.
gfamsdr IOhannes
On Wed, Jul 04, 2012 at 02:46:20PM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-04 13:14, Roman Haefeli wrote:
Keeping the thread talking to the audio back end always running has some advantages:
- The audio card cannot be stolen by other softwares while DSP is
off * A cycle of turning DSP off and on is much faster, since no thread needs to be stopped and started
otoh, releasing the audio backend, allows other software to steal the audio card. i think this is a feature not a bug.
I think it's both... my current plan (which I could be talked out of) would be to add a new option to keep audio device open regardless of DSP being on or off. Probably jack users will want the option 'on' and most others will want it "off".
cheers Miller
On Mit, 2012-07-04 at 09:16 -0700, Miller Puckette wrote:
On Wed, Jul 04, 2012 at 02:46:20PM +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-07-04 13:14, Roman Haefeli wrote:
Keeping the thread talking to the audio back end always running has some advantages:
- The audio card cannot be stolen by other softwares while DSP is
off * A cycle of turning DSP off and on is much faster, since no thread needs to be stopped and started
otoh, releasing the audio backend, allows other software to steal the audio card. i think this is a feature not a bug.
I think it's both... my current plan (which I could be talked out of) would be to add a new option to keep audio device open regardless of DSP being on or off. Probably jack users will want the option 'on' and most others will want it "off".
I was just going to suggest that those could be separate options: DSP on/off, audio back-end connect/disconnect.
This is great! I am also excited.
Cheers Roman
The thing I'm actually looking forward to doing is to extend textfiles
and message boxes and data structures to be able to spit lists of atoms
around much more flexibly than now.
independenly of how many new possibilities would come up from adding lists
to data structures, working with data structures in general is still very
laborious.
I would just like to add if it would be possible to add a couple more
methods to work with pointers. I've made several suggestions in the past,
and can send them again (have them somewhere). Methods like [next x(,
[previous x(, [delete(, etc., would be quite good for more complex things.
Something also quite good would be the possibility of incorporating simple
math expressions in data structure objects. like "x*3" written in the
object, instead of getting the elements, multiplying them, and then
setting them... from what I've seen from ftm, that's a very good resource.
and several other things, but I don't want to hijack the whole thread.
João
Yeah... I'm still trying to figure out how to make data structures less clunky without adding unnecessary complexity... I'm planning to go back and look at that again.
Miller
On Wed, Jul 04, 2012 at 05:37:49PM +0200, João Pais wrote:
The thing I'm actually looking forward to doing is to extend textfiles and message boxes and data structures to be able to spit lists of atoms around much more flexibly than now.
independenly of how many new possibilities would come up from adding lists to data structures, working with data structures in general is still very laborious. I would just like to add if it would be possible to add a couple more methods to work with pointers. I've made several suggestions in the past, and can send them again (have them somewhere). Methods like [next x(, [previous x(, [delete(, etc., would be quite good for more complex things. Something also quite good would be the possibility of incorporating simple math expressions in data structure objects. like "x*3" written in the object, instead of getting the elements, multiplying them, and then setting them... from what I've seen from ftm, that's a very good resource.
and several other things, but I don't want to hijack the whole thread.
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I would find it very simple if a method would allow me to find scalar nr
2571 (I have a patch with many more) by sending the message [traverse
xxxx, bang, next 2571(, than by building a [2571(-[until]-[next(
structure. Or for example, it's impossible (?) to erase scalers without
using the mouse.
Making those simple/trivial operations less laborious to program - i.e.,
incorporate them into [pointer] - could be a good way of making data
structures more accessible. which was anyway, the original drive to create
Pd, as I read in your paper (right?).
or, what was meant with "unnecessary complexity"?
Yeah... I'm still trying to figure out how to make data structures less clunky without adding unnecessary complexity... I'm planning to go back and look at that again.
(taking this off pd-announce - sorry I didn't notice that earlier :)
Yep, it was indeed my original focus, and it's proved hard to make it as wonderful as I keep hoping it will someday be. Anyhow, making traversal more convenient is definitely something I want to do. BEsides the ideas you mentioned, here are two others - first, being ble somehow to name a pointer so somewhere else in the patch you can get what's inside a pointer object - maybe somehow making it more like "v" objects.
Also, making pointers/data structures and "textfile" have many of the same methods (and several more of them) so you can search, trim, reorder, etc.
Much to think about!
cheers Miller On Wed, Jul 04, 2012 at 06:33:49PM +0200, João Pais wrote:
I would find it very simple if a method would allow me to find scalar nr 2571 (I have a patch with many more) by sending the message [traverse xxxx, bang, next 2571(, than by building a [2571(-[until]-[next( structure. Or for example, it's impossible (?) to erase scalers without using the mouse. Making those simple/trivial operations less laborious to program - i.e., incorporate them into [pointer] - could be a good way of making data structures more accessible. which was anyway, the original drive to create Pd, as I read in your paper (right?).
or, what was meant with "unnecessary complexity"?
Yeah... I'm still trying to figure out how to make data structures less clunky without adding unnecessary complexity... I'm planning to go back and look at that again.
Yep, it was indeed my original focus, and it's proved hard to make it as wonderful as I keep hoping it will someday be. Anyhow, making traversal more convenient is definitely something I want to do. BEsides the ideas you mentioned, here are two others - first, being ble somehow to name a pointer so somewhere else in the patch you can get what's
inside a pointer object - maybe somehow making it more like "v" objects.
that would be great, as (pointer)s are an unknown variable. for now the
only way of sorting out a pointer from others is by some kind of
comparison test - i.e. going through all until one finds the right one.
sometimes adding extra variables just to have something to compare with.
that would be good not only to get the contents faster, but also to treat
pointers as individual variables (which they are).
Also, making pointers/data structures and "textfile" have many of the same methods (and several more of them) so you can search, trim, reorder, etc.
that would be great. but already improving traversing would make these methods much easier to program in a patch. for example, adding vnext is already a good help, but only for a specific kind of usage.
Much to think about!
indeed. if you're the VarÚse professorship in the TU Berlin works out (as I heard some months ago), I would be glad to test that directly (and watch the seminars)
Hi Miller, I think the whole gpointer thingy forces Pd users to think about unnecessary details-- like scalar creation order-- just in order to use them, which is exactly why the #1 complaint about them is that nobody understands how to use them. You've designed the rest of Pd to hide just the things data structures reveal. Unfortunately the user doesn'tget expressivity through data structures that would be comparable to just coding a c external, but they do get a (somewhat) comparable level of complexity.
Here's how to make them better:
- Make a public interface out of the trick you're already using to
load pd-_float_array and pd-_float. Users should be able to make a ds library and load that library with the same ease that they load external libraries using [declare], [import], etc. (This will also solve the problem of trying to use a data structure inside an abstraction, where on the one hand the user must use [struct $0-foo], but then that destroys any chance to save and reload state with impugnity.)
- Allow scalar creation by typing the name in an object box. If I
have [struct foo] in a subpatch template I should be able to type [foo] andhave it create a scalar. If I loaded a library named "foo" that includes a template for [struct bar] I should be able to type [bar] or [foo/bar] and have the scalar create. If it's any harder than that to create a scalar then the number of people who will understand and benefit from using data structures will never exceed the number of people who understand and benefit from dynamic patching (which is very few because it's too clunky). If you do these then data structures will be crystal clear: As an abstraction is Pd code analogous to external class in c with default widget behavior So too is A data structure template analogous to an external class in c with custom widget behavior
... with the added benefit that coding up such a data structure doesn't carry the complexity of coding a graphical external class in c.
-Jonathan
p.s. (Experimental) 3) Add a "canvas" or "glist" field to [struct] as I suggested in an earlier email. I don't think João would need to search through a linked list just to find a value if he could have a canvas with the necessary objects in it that is associated with that scalar and its field values.
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: João Pais jmmmpais@googlemail.com Cc: pd-list@iem.at Sent: Wednesday, July 4, 2012 12:43 PM Subject: Re: [PD] [PD-announce] pd 0.43-3 released
(t aking this off pd-announce - sorry I didn't notice that earlier :)
Yep, it was indeed my original focus, and it's proved hard to make it as wonderful as I keep hoping it will someday be. Anyhow, making traversal more convenient is definitely something I want to do. BEsides the ideas you mentioned, here are two others - first, being ble somehow to name a pointer so somewhere else in the patch you can get what's inside a pointer object - maybe somehow making it more like "v" objects.
Also, making pointers/data structures and "textfile" have many of the same methods (and several more of them) so you can search, trim, reorder, etc.
Much to think about!
cheers Miller On Wed, Jul 04, 2012 at 06:33:49PM +0200, João Pais wrote:
I would find it very simple if a method would allow me to find scalar nr 2571 (I have a patch with many more) by sending the message [traverse xxxx, bang, next 2571(, than by building a [2571(-[until]-[next( structure. Or for example, it's impossible (?) to erase scalers without using the mouse. Making those simple/trivial operations less laborious to program - i.e., incorporate them into [pointer] - could be a good way of making data structures more accessible. which was anyway, the original drive to create Pd, as I read in your paper (right?).
or, what was meant with "unnecessary complexity"?
Yeah... I'm still trying to figure out how to make data structures
less
clunky without adding unnecessary complexity... I'm planning to go
back
and look at that again.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
These are good ideas, thanks.
M
On Wed, Jul 04, 2012 at 11:40:57AM -0700, Jonathan Wilkes wrote:
Hi Miller,     I think the whole gpointer thingy forces Pd users to think about unnecessary details-- like scalar creation order-- just in order to use them, which is exactly why the #1 complaint about them is that nobody understands how to use them. You've designed the rest of Pd to hide just the things data structures reveal. Unfortunately the user doesn'tget expressivity through data structures that would be comparable to just coding a c external, but they do get a (somewhat) comparable level of complexity.
Here's how to make them better:
- Make a public interface out of the trick you're already using to
load pd-_float_array and pd-_float. Users should be able to make a ds library and load that library with the same ease that they load external libraries using [declare], [import], etc. (This will also solve the problem of trying to use a data structure inside an abstraction, where on the one hand the user must use [struct $0-foo], but then that destroys any chance to save and reload state with impugnity.)
- Allow scalar creation by typing the name in an object box. If I
have [struct foo] in a subpatch template I should be able to type [foo] andhave it create a scalar. If I loaded a library named "foo" that includes a template for [struct bar] I should be able to type [bar] or [foo/bar] and have the scalar create. If it's any harder than that to create a scalar then the number of people who will understand and benefit from using data structures will never exceed the number of people who understand and benefit from dynamic patching (which is very few because it's too clunky). If you do these then data structures will be crystal clear: As an abstraction is Pd code analogous to external class in c with default widget behavior So too is A data structure template analogous to an external class in c with custom widget behavior
... with the added benefit that coding up such a data structure doesn't carry the complexity of coding a graphical external class in c.
-Jonathan
p.s. (Experimental) 3) Add a "canvas" or "glist" field to [struct] as I suggested in an earlier email. I don't think João would need to search through a linked list just to find a value if he could have a canvas with the necessary objects in it that is associated with that scalar and its field values.
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: João Pais jmmmpais@googlemail.com Cc: pd-list@iem.at Sent: Wednesday, July 4, 2012 12:43 PM Subject: Re: [PD] [PD-announce] pd 0.43-3 released
(t aking this off pd-announce - sorry I didn't notice that earlier :)
Yep, it was indeed my original focus, and it's proved hard to make it as wonderful as I keep hoping it will someday be. Anyhow, making traversal more convenient is definitely something I want to do. BEsides the ideas you mentioned, here are two others - first, being ble somehow to name a pointer so somewhere else in the patch you can get what's inside a pointer object - maybe somehow making it more like "v" objects.
Also, making pointers/data structures and "textfile" have many of the same methods (and several more of them) so you can search, trim, reorder, etc.
Much to think about!
cheers Miller On Wed, Jul 04, 2012 at 06:33:49PM +0200, João Pais wrote:
I would find it very simple if a method would allow me to find scalar nr 2571 (I have a patch with many more) by sending the message [traverse xxxx, bang, next 2571(, than by building a [2571(-[until]-[next( structure. Or for example, it's impossible (?) to erase scalers without using the mouse. Making those simple/trivial operations less laborious to program - i.e., incorporate them into [pointer] - could be a good way of making data structures more accessible. which was anyway, the original drive to create Pd, as I read in your paper (right?).
or, what was meant with "unnecessary complexity"?
Yeah... I'm still trying to figure out how to make data structures
less
clunky without adding unnecessary complexity... I'm planning to go
back
and look at that again.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
the user doesn'tget expressivity through data structures that would be comparable to just coding a c external, but they do get a (somewhat) comparable level of complexity.
yes, the worse is that the enigmatic (gpointer) don't mean anything for
someone that can't read the C code, like me. changing that format for a
symbolic "link" - like "structname-scalarnr" or similar, user-defined -
would make much more sense for users. And also, hopefully, give scalars a
faster way of being accessed (the traversing issue).
Here's how to make them better:
- Make a public interface out of the trick you're already using to
load pd-_float_array and pd-_float. Users should be able to make a ds library and load that library with the same ease that they load external libraries using [declare], [import], etc. (This will also solve the problem of trying to use a data structure inside an abstraction, where on the one hand the user must use [struct $0-foo], but then that destroys any chance to save and reload state with impugnity.)
ah, that one I forgot. for my simple abstractions like [bezier] or
[swatch], the scalars of $0-templates are created on loadbang. but that's
not very handy (or possible?) when loading a score with thousands of
scalars.
- Allow scalar creation by typing the name in an object box. If I
A good complement to that would be scalar manipulation as well. like
sending a message [select scalar-1 scalar-278( to select a range of
scalars, and then move them (without going to the x/y fields of each one),
duplicating, erasing, copy/pasting, ...
(Experimental) 3) Add a "canvas" or "glist" field to [struct] as I
suggested in an earlier email. I don't think João would need to search through a linked list
just to find a value if he could have a canvas with the necessary objects in it that is associated with that scalar and its field values.
I didn't understood that, but it sounds very important, my name is in that
paragraph.
João
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Miller Puckette msp@ucsd.edu; Jonathan Wilkes jancsika@yahoo.com Cc: "pd-list@iem.at" pd-list@iem.at Sent: Wednesday, July 4, 2012 7:38 PM Subject: Re: [PD] [PD-announce] pd 0.43-3 released
the user doesn'tget expressivity through data structures that would be comparable to just coding a c external, but they do get a (somewhat) comparable level of complexity.
yes, the worse is that the enigmatic (gpointer) don't mean anything for someone that can't read the C code, like me. changing that format for a symbolic "link" - like "structname-scalarnr" or similar, user-defined - would make much more sense for users. And also, hopefully, give scalars a faster way of being accessed (the traversing issue).
Here's how to make them better:
- Make a public interface out of the trick you're already using to
load pd-_float_array and pd-_float. Users should be able to make a ds library and load that library with the same ease that they load external libraries using [declare], [import], etc. (This will also solve the problem of trying to use a data structure inside an abstraction, where on the one hand the user must use [struct $0-foo], but then that destroys any chance to save and reload state with impugnity.)
ah, that one I forgot. for my simple abstractions like [bezier] or [swatch], the scalars of $0-templates are created on loadbang. but that's not very handy (or possible?) when loading a score with thousands of scalars.
- Allow scalar creation by typing the name in an object box. If I
A good complement to that would be scalar manipulation as well. like sending a message [select scalar-1 scalar-278( to select a range of scalars, and then move them (without going to the x/y fields of each one), duplicating, erasing, copy/pasting, ...
(Experimental) 3) Add a "canvas" or "glist" field to
[struct] as I suggested in an earlier
email. I don't think João would need to search through a linked list
just to find a
value if he could have a canvas with the necessary objects in it that is associated with that scalar and its field values.
I didn't understood that, but it sounds very important, my name is in that paragraph.
:)
When you create an abstraction, you basically save a patch that is a template for all instances of the abstraction which you will create later. [f $1] gets filled in with the first arg, [symbol $2] with the second arg, and so on.
With my idea, you create a scalar that has an associated canvas (similar to an abstraction), and that canvas has access to the field values for that scalar.
Example: let's say you have [struct foo float y symbol blah canvas bar], and have a subpatch [pd bar] that is a template for the field "bar" which is just a canvas. So when you create a scalar foo, that scalar has a y variable-- which is a float; a blah variable-- which is a symbol; and a bar variable-- which is a canvas. Imagine a hypothetical object inside that scalar's canvas called [getmy y], and when you bang it you get the y value associated with _this_ scalar. Now imagine this inside bar:
[getmy y] | [mtof] | [osc~] | [catch~ bus]
Now if you instantiate 16 scalars, each one of them has an associated oscillator that gets its pitch from that scalar's y value. In other words, each scalar also has a canvas that holds within it the means to produce sound from the y value that you see.
I'm just assuming here that [getmy] would work like the outlet of [struct]-- that is, it sends out a message when the y value for that scalar is updated. (Or alternatively when it is banged.)
Better yet, imagine using "foo" as the template for another struct as in the following: [struct container float x float y array z foo]
Now you can create/destroy voices in an oscbank using [setsize]! Of course I'm skipping over lots of details, like you'd still have to rebuild the dsp graph, and how loadbang would or woudn't work when you instantiate a scalar with a canvas field, etc., etc.
Hopefully some of that makes sense.
-Jonathan
João
nice on the 04.4, a way to modulate the phase sync sounds good. It sounds pretty good at block size 64 anyways but I guess it would be better faster. I'll give you my ltoa if you will make something so that I can change "1/4" loaded from a textfile into 0.25.
yes, now it makes more sense. that could be very sexy, as besides all the
interesting ideas, it would be possible to have a only-graphical version
of Pd running, for people who are only users.
it might not be very practical for cases where canvases have more than a
certain number of scalars (I have some with a couple thousands), but very
nice for other issues.
João
When you create an abstraction, you basically save a patch that is a
template for all instances of the abstraction which you will create later. [f
$1] gets filled in with the first arg, [symbol $2] with the second arg, and so on.With my idea, you create a scalar that has an associated canvas (similar
to an abstraction), and that canvas has access to the field values for that
scalar.Example: let's say you have [struct foo float y symbol blah canvas bar],
and have a subpatch [pd bar] that is a template for the field "bar" which is
just a canvas. So when you create a scalar foo, that scalar has a y variable--
which is a float; a blah variable-- which is a symbol; and a bar variable-- which
is a canvas. Imagine a hypothetical object inside that scalar's canvas called [getmy
y], and when you bang it you get the y value associated with _this_ scalar. Now
imagine this inside bar:[getmy y] | [mtof] | [osc~] | [catch~ bus]
Now if you instantiate 16 scalars, each one of them has an associated
oscillator that gets its pitch from that scalar's y value. In other words, each
scalar also has a canvas that holds within it the means to produce sound from the y
value that you see.I'm just assuming here that [getmy] would work like the outlet of
[struct]-- that is, it sends out a message when the y value for that scalar is updated. (Or
alternatively when it is banged.)Better yet, imagine using "foo" as the template for another struct as in
the following: [struct container float x float y array z foo]Now you can create/destroy voices in an oscbank using [setsize]! Of
course I'm skipping over lots of details, like you'd still have to rebuild the dsp
graph, and how loadbang would or woudn't work when you instantiate a scalar with a
canvas field, etc., etc.Hopefully some of that makes sense.
-Jonathan
João
Hi Miller, Thanks for including two libpd-related patches in Pd 0.43-3! I merged your changes into the (still experimental) opensl branch of libpd and everything seems to be working nicely. In particular, building and deploying externals for Android is perfectly straightforward now. Cheers, Peter
On Tue, Jul 3, 2012 at 5:11 PM, Miller Puckette msp@ucsd.edu wrote:
Hi all,
Pd version 0.43-3 is available on http://crca.ucsd.edu/~msp/software.htm or via git from sourceforge: git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data
Main change from 0.43-2 is that MIDI input is improved on Mac and Windows.
Also, I added a stub to future-proof Pd against a possible extension of the file format so that in the future there could be a way to set widths of boxes and stuff like that (and 0.43-3 would read those files and only complain once instead of complaining for pages.)
I'm ready to start hacking on 0.44. The most urgent thing seems to be for me to go back and work on the audio system (and perhaps tweak MIDI a bit more too).
The thing I'm actually looking forward to doing is to extend textfiles and message boxes and data structures to be able to spit lists of atoms around much more flexibly than now.
Also pd vanilla needs tilde objects to do interpolating signal snapshots, phase-syncable oscillators, and other stuff on that level, also likely to be a lot of fun.
cheers Miller
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
-
Billy Stiltner -
Chris McCormick -
Chrissie Caulfield -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
James Dunn -
Jonathan Wilkes -
João Pais -
Miller Puckette -
Peter Brinkmann -
Roman Haefeli