Re: [PD] [PD-announce] pd 0.43-3 released
Its included now but in 0.44: http://pure-data.git.sourceforge.net/git/gitweb.cgi?p=pure-data/pure-data;a=commit;h=153c8c9a18acb4b89bd9242f5c5dc9d03eece4e8 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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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 -- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmp...@googlemail.com | skype: jmmmpjmmmp ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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 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-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] [PD-announce] pd 0.43-3 released
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. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
- Original Message - > From: João Pais > To: Miller Puckette ; Jonathan Wilkes > Cc: "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: >> 1) 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. > > >> 2) 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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: 1) 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. 2) 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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: > 1) 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.) > > > 2) 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 > > To: João Pais > > 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 , 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 > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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: 1) 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.) 2) 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 > To: João Pais > 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 , 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
(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 , 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
Re: [PD] [PD-announce] pd 0.43-3 released
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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 , 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
Re: [PD] [PD-announce] pd 0.43-3 released
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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
Re: [PD] [PD-announce] pd 0.43-3 released
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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/0OxkACgkQkX2Xpv6ydvSpvwCglItsYSzng6ZGuLkBJpVUeJI+ oD8AoJT8My4WS9X61eM40jE6WOoHZbmj =cSq1 -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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
Re: [PD] [PD-announce] pd 0.43-3 released
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] [PD-announce] pd 0.43-3 released
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. -- http://mccormick.cx/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
[PD] [PD-announce] pd 0.43-3 released
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-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
