Hi all,
I'm now ready to start working toward the next Pd release (0.48) . I've barely touched the Pd sources since the 0.47-1 release last June, and meanwhile picked up lots of ideas from the Pd convention and always have my own long list of things to do. In the interest of transparency I'll try to map out my plans for the 3-ish months I think it will take me to get to 0.48.
I'll only be advancing rather slowly before Feb. 4 because I have two separate music production projects before then; I'll start working faster after that.
First thing is always to merge in as many patches and pull requests as I can. I get these from two sources: sourceforge (https://sourceforge.net/p/pure-data/patches/) and github (https://github.com/pure-data/pure-data/pulls). At the moment I don't prioritize one of those above the other. I do this first because, when I enter a period of heavy code editing I risk causing conflicts with patches/pull requests and I don't want to create extra work for contributors.
In a few days I'll start on my own changes, with the major ones first so that there's extras time to get them decently debugged; then while bugs in the major changes are surfacing I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
offer an option to delete all "system" preferences ("defaults" on mac; registry info on Windows).
the code has diverged I'll probably have to extensively rewrite it to work in Pd vanilla.
signals connected and, if not, avoid having Pd automatically generate fake signals for them to use. This way, for example, "+~" can finally detect whether it's got a signal connected without having the user have to tell it via "+~ 0". Also, then the filters (hip~ etc) can then be upgraded to allow signals for filter parameters, without doing the extra calculations if there's no signal connected. This will require adding something to the "DSP" mechanism; I'm still not sure how to do this in the best way.
option for netsend/netreceive (I'm not sure if that's needed or not - maybe the existing "-b" binary formatting can be used in conjunction with some new formatting/parsing objects to allow passing floats and symbols around in binary messages instead.)
This is a long list and I probably won't get to all of it. Then I'll move onto all the smaller changes, which are too numerous to list here.
I wonder if we could get the additional [inlet~] features in there too. Maybe someone has a branch with some of those?
I believe they were:
in their left most inlet like other (first class?) objects.. and, for instance, clone with only signal inlets can still accept messages in its left most inlet. 2) another outlet to indicate if a signal is actually attached to the abstraction's inlet.
The DSP signal connection sensing could be quite nice so that we could create abstractions and externals that fade in/fade out when signal connections are connected or disconnected.. nicer for live patching..
On Sun, Jan 1, 2017 at 12:32 PM, Miller Puckette msp@ucsd.edu wrote:
Hi all,
I'm now ready to start working toward the next Pd release (0.48) . I've barely touched the Pd sources since the 0.47-1 release last June, and meanwhile picked up lots of ideas from the Pd convention and always have my own long list of things to do. In the interest of transparency I'll try to map out my plans for the 3-ish months I think it will take me to get to 0.48.
I'll only be advancing rather slowly before Feb. 4 because I have two separate music production projects before then; I'll start working faster after that.
First thing is always to merge in as many patches and pull requests as I can. I get these from two sources: sourceforge (https://sourceforge.net/p/pure-data/patches/) and github (https://github.com/pure-data/pure-data/pulls). At the moment I don't prioritize one of those above the other. I do this first because, when I enter a period of heavy code editing I risk causing conflicts with patches/pull requests and I don't want to create extra work for contributors.
In a few days I'll start on my own changes, with the major ones first so that there's extras time to get them decently debugged; then while bugs in the major changes are surfacing I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
- Make a stab at making Pdlib callable from multiple threads. There's a
suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
- fix "preferences" so that you can load/store them explicitly to files,
and offer an option to delete all "system" preferences ("defaults" on mac; registry info on Windows).
- Adapt and incorporate the Pd-llork/purr-data "infinite undo" feature.
Since the code has diverged I'll probably have to extensively rewrite it to work in Pd vanilla.
- fix the DSP sorting mechanism so that objects can sense whether they
have signals connected and, if not, avoid having Pd automatically generate fake signals for them to use. This way, for example, "+~" can finally detect whether it's got a signal connected without having the user have to tell it via "+~ 0". Also, then the filters (hip~ etc) can then be upgraded to allow signals for filter parameters, without doing the extra calculations if there's no signal connected. This will require adding something to the "DSP" mechanism; I'm still not sure how to do this in the best way.
- Make a binary "FUDI" format for pd~ objects, and perhaps also offer it
as an option for netsend/netreceive (I'm not sure if that's needed or not - maybe the existing "-b" binary formatting can be used in conjunction with some new formatting/parsing objects to allow passing floats and symbols around in binary messages instead.)
- Hack at sigmund~ to add some features it needs.
This is a long list and I probably won't get to all of it. Then I'll move onto all the smaller changes, which are too numerous to list here.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Both that and a text-object upgrade are on the dolist... I need to think carefull about how exactly to do this in the most future-proof way, as usual...
cheers M
On Mon, Jan 02, 2017 at 09:15:59AM -0800, Alex wrote:
I wonder if we could get the additional [inlet~] features in there too. Maybe someone has a branch with some of those?
I believe they were:
- a control outlet so that abstractions can take both signals and controls
in their left most inlet like other (first class?) objects.. and, for instance, clone with only signal inlets can still accept messages in its left most inlet. 2) another outlet to indicate if a signal is actually attached to the abstraction's inlet.
The DSP signal connection sensing could be quite nice so that we could create abstractions and externals that fade in/fade out when signal connections are connected or disconnected.. nicer for live patching..
On Sun, Jan 1, 2017 at 12:32 PM, Miller Puckette msp@ucsd.edu wrote:
Hi all,
I'm now ready to start working toward the next Pd release (0.48) . I've barely touched the Pd sources since the 0.47-1 release last June, and meanwhile picked up lots of ideas from the Pd convention and always have my own long list of things to do. In the interest of transparency I'll try to map out my plans for the 3-ish months I think it will take me to get to 0.48.
I'll only be advancing rather slowly before Feb. 4 because I have two separate music production projects before then; I'll start working faster after that.
First thing is always to merge in as many patches and pull requests as I can. I get these from two sources: sourceforge (https://sourceforge.net/p/pure-data/patches/) and github (https://github.com/pure-data/pure-data/pulls). At the moment I don't prioritize one of those above the other. I do this first because, when I enter a period of heavy code editing I risk causing conflicts with patches/pull requests and I don't want to create extra work for contributors.
In a few days I'll start on my own changes, with the major ones first so that there's extras time to get them decently debugged; then while bugs in the major changes are surfacing I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
- Make a stab at making Pdlib callable from multiple threads. There's a
suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
- fix "preferences" so that you can load/store them explicitly to files,
and offer an option to delete all "system" preferences ("defaults" on mac; registry info on Windows).
- Adapt and incorporate the Pd-llork/purr-data "infinite undo" feature.
Since the code has diverged I'll probably have to extensively rewrite it to work in Pd vanilla.
- fix the DSP sorting mechanism so that objects can sense whether they
have signals connected and, if not, avoid having Pd automatically generate fake signals for them to use. This way, for example, "+~" can finally detect whether it's got a signal connected without having the user have to tell it via "+~ 0". Also, then the filters (hip~ etc) can then be upgraded to allow signals for filter parameters, without doing the extra calculations if there's no signal connected. This will require adding something to the "DSP" mechanism; I'm still not sure how to do this in the best way.
- Make a binary "FUDI" format for pd~ objects, and perhaps also offer it
as an option for netsend/netreceive (I'm not sure if that's needed or not - maybe the existing "-b" binary formatting can be used in conjunction with some new formatting/parsing objects to allow passing floats and symbols around in binary messages instead.)
- Hack at sigmund~ to add some features it needs.
This is a long list and I probably won't get to all of it. Then I'll move onto all the smaller changes, which are too numerous to list here.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Happy new year!
sounds great, I'm looking forward to the new release!
just a couple of randoms ideas which have been in my head for a while:
a) a new list method (let's say [list get]) with which you can retrieve one or more elements of a stored list. the rightmost inlet could store a list. A middle inlet could set the length of the desired sublist (default = 1) and the hot leftmost inlet takes a float as the onset (or a bang). This is just one possible interface, taken from [array] and [text]. The point is, that one can finally iterate over a list arbitrarily and in linear time! Right now, the only possible vanilla solution for random access is [bang( -> [list] -> [list split] which results in many unnecessary copies of the whole list. Finally, it would make sequencing lists (in either direction) trivial and more efficient. b) a method for sorting c) a method for reversing d) a method for searching (outputting the indices of found elements) (I know, there are externals for b), c) and d) but since these are quite common tasks (and awkward/inefficient to patch) it would make sense to have those methods in vanilla.
a) it would be great if soundfiler, readsf~, text etc. would send some kind of message which tells whether a file was loaded successfully. Right now, these objects only throw errors in the Pd console, which the user can't catch within the patch. b) when you write a file, all folders in a given path must exist. It would, however, be nice if Pd would automatically create non-existing folders. c) some vanilla way to query a folder for existing files...
a) a way to compare pointers for equality! b) clicking on array elements should output a pointer to the clicked element and not only to the struct containing the array. c) a way to toggle the -x flag. sometimes one wants to lock/unlock editing just temporarily. d) right now, the -x flag prevents both moving the scalar in edit mode AND moving vertices in non-edit mode. Often you only want one of the two behaviours. [ c) would actually provide a workaround for this: you just need to track the current edit mode (e.g. with [iemguts/receivecanvas]) and toggle the -x flag accordingly. ]
Thanks for your awesome work!
Christof
Gesendet: Sonntag, 01. Januar 2017 um 21:32 Uhr Von: "Miller Puckette" msp@ucsd.edu An: pd-list@iem.at Betreff: [PD] plans for Pd 0.48
Hi all,
I'm now ready to start working toward the next Pd release (0.48) . I've barely touched the Pd sources since the 0.47-1 release last June, and meanwhile picked up lots of ideas from the Pd convention and always have my own long list of things to do. In the interest of transparency I'll try to map out my plans for the 3-ish months I think it will take me to get to 0.48.
I'll only be advancing rather slowly before Feb. 4 because I have two separate music production projects before then; I'll start working faster after that.
First thing is always to merge in as many patches and pull requests as I can. I get these from two sources: sourceforge (https://sourceforge.net/p/pure-data/patches/) and github (https://github.com/pure-data/pure-data/pulls). At the moment I don't prioritize one of those above the other. I do this first because, when I enter a period of heavy code editing I risk causing conflicts with patches/pull requests and I don't want to create extra work for contributors.
In a few days I'll start on my own changes, with the major ones first so that there's extras time to get them decently debugged; then while bugs in the major changes are surfacing I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
- Make a stab at making Pdlib callable from multiple threads. There's a
suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
- fix "preferences" so that you can load/store them explicitly to files, and
offer an option to delete all "system" preferences ("defaults" on mac; registry info on Windows).
- Adapt and incorporate the Pd-llork/purr-data "infinite undo" feature. Since
the code has diverged I'll probably have to extensively rewrite it to work in Pd vanilla.
- fix the DSP sorting mechanism so that objects can sense whether they have
signals connected and, if not, avoid having Pd automatically generate fake signals for them to use. This way, for example, "+~" can finally detect whether it's got a signal connected without having the user have to tell it via "+~ 0". Also, then the filters (hip~ etc) can then be upgraded to allow signals for filter parameters, without doing the extra calculations if there's no signal connected. This will require adding something to the "DSP" mechanism; I'm still not sure how to do this in the best way.
- Make a binary "FUDI" format for pd~ objects, and perhaps also offer it as an
option for netsend/netreceive (I'm not sure if that's needed or not - maybe the existing "-b" binary formatting can be used in conjunction with some new formatting/parsing objects to allow passing floats and symbols around in binary messages instead.)
- Hack at sigmund~ to add some features it needs.
This is a long list and I probably won't get to all of it. Then I'll move onto all the smaller changes, which are too numerous to list here.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Miller, just as a reminder
- Make a stab at making Pdlib callable from multiple threads. There's a
suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
the devel_0_39 branch had a contribution by Tim Blechmann, where gensym access to existing symbols was thread-safe - the lock was only necessary for the creation of new symbols. As far as i know, there should be lock-free/wait-free hash tables available in the meantime.
best, Thomas
My #1 request is to be able to index into long arrays using the standard phasor~, tabread4~ combo without loss of precision or complex hacks.
I have not been able to master the use of the onset inlet, and would prefer a simple solution (from a user's perspective anyway) like the Pd Double approach taken by Katja. Maybe at least improve the help file demonstrating how the onset inlet works?
I deal with audio files commonly which are 1-2 hrs long. Would be wonderful to be able to mangle them with Pd.
Thanks for Pd!! It brings me joy every day.
On Sunday, January 1, 2017, Miller Puckette msp@ucsd.edu wrote:
Hi all,
I'm now ready to start working toward the next Pd release (0.48) . I've barely touched the Pd sources since the 0.47-1 release last June, and meanwhile picked up lots of ideas from the Pd convention and always have my own long list of things to do. In the interest of transparency I'll try to map out my plans for the 3-ish months I think it will take me to get to 0.48.
I'll only be advancing rather slowly before Feb. 4 because I have two separate music production projects before then; I'll start working faster after that.
First thing is always to merge in as many patches and pull requests as I can. I get these from two sources: sourceforge (https://sourceforge.net/p/pure-data/patches/) and github (https://github.com/pure-data/pure-data/pulls). At the moment I don't prioritize one of those above the other. I do this first because, when I enter a period of heavy code editing I risk causing conflicts with patches/pull requests and I don't want to create extra work for contributors.
In a few days I'll start on my own changes, with the major ones first so that there's extras time to get them decently debugged; then while bugs in the major changes are surfacing I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
- Make a stab at making Pdlib callable from multiple threads. There's a
suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
- fix "preferences" so that you can load/store them explicitly to files,
and offer an option to delete all "system" preferences ("defaults" on mac; registry info on Windows).
- Adapt and incorporate the Pd-llork/purr-data "infinite undo" feature.
Since the code has diverged I'll probably have to extensively rewrite it to work in Pd vanilla.
- fix the DSP sorting mechanism so that objects can sense whether they
have signals connected and, if not, avoid having Pd automatically generate fake signals for them to use. This way, for example, "+~" can finally detect whether it's got a signal connected without having the user have to tell it via "+~ 0". Also, then the filters (hip~ etc) can then be upgraded to allow signals for filter parameters, without doing the extra calculations if there's no signal connected. This will require adding something to the "DSP" mechanism; I'm still not sure how to do this in the best way.
- Make a binary "FUDI" format for pd~ objects, and perhaps also offer it
as an option for netsend/netreceive (I'm not sure if that's needed or not - maybe the existing "-b" binary formatting can be used in conjunction with some new formatting/parsing objects to allow passing floats and symbols around in binary messages instead.)
- Hack at sigmund~ to add some features it needs.
This is a long list and I probably won't get to all of it. Then I'll move onto all the smaller changes, which are too numerous to list here.
Pd-list@lists.iem.at javascript:; mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
I'm planning (someday!) to write a helper abstraction to manage this :)
M
On Mon, Jan 02, 2017 at 02:28:04PM -0500, William Huston wrote:
My #1 request is to be able to index into long arrays using the standard phasor~, tabread4~ combo without loss of precision or complex hacks.
I have not been able to master the use of the onset inlet, and would prefer a simple solution (from a user's perspective anyway) like the Pd Double approach taken by Katja. Maybe at least improve the help file demonstrating how the onset inlet works?
I deal with audio files commonly which are 1-2 hrs long. Would be wonderful to be able to mangle them with Pd.
Thanks for Pd!! It brings me joy every day.
Hello list,
just to ask if there is any ruling on the Apple Human Interface Guidelines for the "apply" button in properties. This really makes programming GUI very time wasting. I do not know it what stage is this in. I know the other topics being discussed are more important in a deeper programming sense, but these little things add up a lot of time when programming.
cheers
On Mon, Jan 2, 2017 at 7:33 PM, Miller Puckette msp@ucsd.edu wrote:
I'm planning (someday!) to write a helper abstraction to manage this :)
M
On Mon, Jan 02, 2017 at 02:28:04PM -0500, William Huston wrote:
My #1 request is to be able to index into long arrays using the standard phasor~, tabread4~ combo without loss of precision or complex hacks.
I have not been able to master the use of the onset inlet, and would
prefer
a simple solution (from a user's perspective anyway) like the Pd Double approach taken by Katja. Maybe at least improve the help file
demonstrating
how the onset inlet works?
I deal with audio files commonly which are 1-2 hrs long. Would be
wonderful
to be able to mangle them with Pd.
Thanks for Pd!! It brings me joy every day.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
In the meantime, try [tabread4~~] from zexy. the second inlet is audio rate.
I guess, if Miller implements the automatic signal detection, [tabread4~] and [delread4~] could also get signal inlets, since there won't be a performance impact if you only send floats.
Christof
Gesendet: Montag, 02. Januar 2017 um 20:28 Uhr Von: "William Huston" williamahuston@gmail.com An: "Miller Puckette" msp@ucsd.edu Cc: "pd-list@iem.at" pd-list@iem.at Betreff: Re: [PD] plans for Pd 0.48 My #1 request is to be able to index into long arrays using the standard phasor~, tabread4~ combo without loss of precision or complex hacks. I have not been able to master the use of the onset inlet, and would prefer a simple solution (from a user's perspective anyway) like the Pd Double approach taken by Katja. Maybe at least improve the help file demonstrating how the onset inlet works? I deal with audio files commonly which are 1-2 hrs long. Would be wonderful to be able to mangle them with Pd. Thanks for Pd!! It brings me joy every day. On Sunday, January 1, 2017, Miller Puckette <msp@ucsd.edu[mailto:msp@ucsd.edu]> wrote:Hi all,
I'm now ready to start working toward the next Pd release (0.48) . I've barely touched the Pd sources since the 0.47-1 release last June, and meanwhile picked up lots of ideas from the Pd convention and always have my own long list of things to do. In the interest of transparency I'll try to map out my plans for the 3-ish months I think it will take me to get to 0.48.
I'll only be advancing rather slowly before Feb. 4 because I have two separate music production projects before then; I'll start working faster after that.
First thing is always to merge in as many patches and pull requests as I can. I get these from two sources: sourceforge (https://sourceforge.net/p/pure-data/patches/%5Bhttps://sourceforge.net/p/pur...]) and github (https://github.com/pure-data/pure-data/pulls%5Bhttps://github.com/pure-data/... At the moment I don't prioritize one of those above the other. I do this first because, when I enter a period of heavy code editing I risk causing conflicts with patches/pull requests and I don't want to create extra work for contributors.
In a few days I'll start on my own changes, with the major ones first so that there's extras time to get them decently debugged; then while bugs in the major changes are surfacing I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
1. Make a stab at making Pdlib callable from multiple threads. There's a suggestion from Peter Brinkmann in which gensym() (and I presume by extension, pd_bind() etc) would be protected by a lock. I have an alternative idea I'd like to float; I'll do this in a separate message to follow.
2. fix "preferences" so that you can load/store them explicitly to files, and offer an option to delete all "system" preferences ("defaults" on mac; registry info on Windows).
3. Adapt and incorporate the Pd-llork/purr-data "infinite undo" feature. Since the code has diverged I'll probably have to extensively rewrite it to work in Pd vanilla.
signals connected and, if not, avoid having Pd automatically generate fake signals for them to use. This way, for example, "+~" can finally detect whether it's got a signal connected without having the user have to tell it via "+~ 0". Also, then the filters (hip~ etc) can then be upgraded to allow signals for filter parameters, without doing the extra calculations if there's no signal connected. This will require adding something to the "DSP" mechanism; I'm still not sure how to do this in the best way.
5. Make a binary "FUDI" format for pd~ objects, and perhaps also offer it as an option for netsend/netreceive (I'm not sure if that's needed or not - maybe the existing "-b" binary formatting can be used in conjunction with some new formatting/parsing objects to allow passing floats and symbols around in binary messages instead.)
This is a long list and I probably won't get to all of it. Then I'll move onto all the smaller changes, which are too numerous to list here.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
--
-- May you, and all beings be happy and free from suffering :) -- ancient Buddhist Prayer (Metta) _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
On 2017-01-01 21:32, Miller Puckette wrote:
This is a long list [...]
another wishlist from my side (which I wanted to address at PdCon16~ but somehow didn't manage). would it be possible to include the libpd glue into the proper Pd sources? i'm only talking about the C-part of libpd as found in the folder [libpd_wrapper], not about the various language bindings.
the idea is:
the paths to some files in the main Makefile)
(very) thin libraries that dynamically link against libpd.so
the main reasoning is, that i would like to have libpd in Debian/Ubuntu/... proper, and they are very peculiar about code duplication, that is: it's forbidden by policy to include the same non-trivial sources twice in the archives; however, the current model of libpd source distribution does exactly this. being able to build libpd directly from pd-vanilla would greatly simplify things for me.
the important question is of course, whether the various language wrappers would be able to use a common libpd.so - if not, the entire exercise might be moot. afaict, the wrappers currently use static linking, but that might just be for convenience reasons. it would be interesting to hear peter and dan (or some other libpd experts) on this.
on the long run, i'm dreaming of pd-vanilla using libpd directly (that is, dynamically linking against libpd.so like other applications, rather than statically including it). but that's probably for 0.48-1 :-)
asdfmr IOhannes
[libpd_wrapper] https://github.com/libpd/libpd/tree/master/libpd_wrapper
On 2017-01-01 21:32, Miller Puckette wrote:
I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
here's another one that emerged from my wishlist, after the few mentions of [clone] in the last days:
add a method to clone to change the number of instances. i understand that this is not a realtime operation, but a use-case could look like:
or:
passes the voice-number to Pd via "-send num_voices ${VOICES}", which passes the voice-number to [clone])
fgmasdr IOhannes
And another use case - non-real-time (batch) audio rendering as in csound where you just allocate instances as you need 'em. This definitely needs doing.
cheers M
On Thu, Jan 05, 2017 at 04:45:15PM +0100, IOhannes m zmoelnig wrote:
On 2017-01-01 21:32, Miller Puckette wrote:
I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
here's another one that emerged from my wishlist, after the few mentions of [clone] in the last days:
add a method to clone to change the number of instances. i understand that this is not a realtime operation, but a use-case could look like:
- at startup, run a profiling patch estimating the CPU power of the machine.
- use that info to determine the number of voices my synth can handle today.
or:
- specify the number voices via a startup flag (to my script, which
passes the voice-number to Pd via "-send num_voices ${VOICES}", which passes the voice-number to [clone])
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
re: moog, re:dir /* Engine Driven Module Program
*/
//[[[[[[[[[[[[[[[[[[[[[[[[[[<Setup Module>]]]]]]]]]]]]]]]]]]]]]]]]]]]]] #include <iostream.h> #include <conio.h> int state; int _state; int count; int wait; long double a1,b1,c1,a2,b2,c2,a3,b3,c3,z1,z2,z3,k1,k2,k3; long double x,y,z,detn; int input_mod(void); int trip_simul(void); int exit_mod(void); //[[[[[[[[[[[[[[[[[[[[[[[[[[<<<<<<<>>>>>>>]]]]]]]]]]]]]]]]]]]]]]]]]]]]]*/
//[[[[[[[[[[[[[[[[[[[[[[[[[[<Engine Module>]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] main() { count=0; while (count<100) {//++++++++++++++++++++++<Engine Loop>+++++++++++++++++++++++++ switch (_state) { case 0:{ input_mod(); break; }; case 1:{ trip_simul(); break; };
case 2:{
exit_mod();
break;
};
};
};//++++++++++++++++++++++<<<<<<<>>>>>>+++++++++++++++++++++++++
return(0); }; //[[[[[[[[[[[[[[[[[[[[[[[[[[<<<<<<<>>>>>>>]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
// <<<<input_mod>>>> int input_mod(void) { clrscr(); cout<<"1 for a triple simultaneous equation 2 for exit ";
cin>>_state;
return(_state); }; // <<<<<<<>>>>>>>
// <<<<trip_sim>>>> int trip_simul(void) { clrscr(); cout<<"a1*x+b1*y+c1*z=k1\n"; cout<<"a2*x+b2*y+c2*z=k2\n"; cout<<"a3*x+b3*y+c3*z=k3\n";
cout<<"\nwhat is a1 = ";
cin>>a1;
cout<<"what is b1 = ";
cin>>b1;
cout<<"what is c1 = ";
cin>>c1;
cout<<"what is k1 = ";
cin>>k1;
cout<<"\nwhat is a2 = ";
cin>>a2;
cout<<"what is b2 = ";
cin>>b2;
cout<<"what is c2 = ";
cin>>c2;
cout<<"what is k2 = ";
cin>>k2;
cout<<"\nwhat is a3 = ";
cin>>a3;
cout<<"what is b3 = ";
cin>>b3;
cout<<"what is c3 = ";
cin>>c3;
cout<<"what is k3 = ";
cin>>k3;
detn=(((a1*b2*c3)+(b1*c2*a3)+(c1*a2*b3))-((a3*b2*c1)+(b3*c2*a1)+(c3*a2*b1))); x=((((k1*b2*c3)+(b1*c2*k3)+(c1*k2*b3))-((k3*b2*c1)+(b3*c2*k1)+(c3*k2*b1)))/detn); y=((((a1*k2*c3)+(k1*c2*a3)+(c1*a2*k3))-((a3*k2*c1)+(k3*c2*a1)+(c3*a2*k1)))/detn); z=((((a1*b2*k3)+(b1*k2*a3)+(k1*a2*b3))-((a3*b2*k1)+(b3*k2*a1)+(k3*a2*b1)))/detn); cout<<"\nx = "<<x<<"\n"; cout<<"y = "<<y<<"\n"; cout<<"z = "<<z<<"\n"; getch(); _state=0; return(_state); }; // <<<<<<<>>>>>>>
int exit_mod(void) { cout<<"see ya"; count = 101; return (count); };
//cgidir copyright 1996 Billy Stiltner #include <stdio.h> #include "g:\bc45\cgic\cgic105\cgic.h" #include <dir.h> #include <dos.h> FILE *in, *out; struct ffblk f; char drive[3],dir[66],name[9],ext[5]; int done;
char pathname[81]; char ConfigUrl[255]; char ConfigDir[255]; int cgiMain() { #if DEBUG /* Load a saved CGI scenario if we're debugging */ cgiReadEnvironment("/home/boutell/public_html/capcgi.dat"); #endif
cgiHeaderContentType("text/html");
/*cgiHeaderLocation("http://206.151.77.100/output.htm");*/ fprintf(cgiOut, "<HTML><HEAD>\n"); fprintf(cgiOut, "<TITLE>Stiltner's Web Directory</TITLE></HEAD>\n"); fprintf(cgiOut, "<BODY>Stiltner's Web Directory Copyright 1996 Billy Stiltner<BR>\n");
if((in = fopen("\cgidir\cgidir.cfg", "r+")) == NULL) { fprintf(cgiOut, "Cannot open configuration file.\n"); return 1; }else{ fgets(ConfigUrl,255,in); fgets(ConfigDir,255,in); fprintf(cgiOut,ConfigUrl); fprintf(cgiOut,ConfigDir); // fprintf(cgiOut, "<form method="POST" action=" http://206.151.77.100/scripts/cgidir.exe%5C%22%3E"); fprintf(cgiOut, "<form method="POST" action="); fprintf(cgiOut, ConfigUrl); fprintf(cgiOut, ">"); };
fprintf(cgiOut, "<HR><BR>\n");
cgiFormStringNoNewlines("pathname", pathname, 81);
fprintf(cgiOut, "Directory of %s<BR>\n", pathname);
fprintf(cgiOut, "<HR>");
done = findfirst(pathname,&f,63);
while (!done)
{
fnsplit(f.ff_name,drive,dir,name,ext);
if(f.ff_attrib==FA_DIREC){
fprintf(cgiOut,"<IMG SRC=\"/dir.gif\" HEIGHT=13 WIDTH=15>");
}else{
fprintf(cgiOut,"<IMG SRC=\"/file.gif\" HEIGHT=16 WIDTH=13>");};
fprintf(cgiOut, f.ff_name); fprintf(cgiOut, "<BR>\n");
done = findnext(&f);
}
fprintf(cgiOut, "<HR>");
fprintf(cgiOut, "Path:<input type=\"text\"
name="pathname"><BR>\n<BR>\n"); fprintf(cgiOut, "<input type="submit" name="submit1" value="Get Directory">");
fprintf(cgiOut, "</form>"); fprintf(cgiOut, "</BODY></HTML>\n"); return 0; }
On Thu, Jan 5, 2017 at 10:55 AM, Miller Puckette msp@ucsd.edu wrote:
And another use case - non-real-time (batch) audio rendering as in csound where you just allocate instances as you need 'em. This definitely needs doing.
cheers M
On Thu, Jan 05, 2017 at 04:45:15PM +0100, IOhannes m zmoelnig wrote:
On 2017-01-01 21:32, Miller Puckette wrote:
I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
here's another one that emerged from my wishlist, after the few mentions of [clone] in the last days:
add a method to clone to change the number of instances. i understand that this is not a realtime operation, but a use-case could look like:
- at startup, run a profiling patch estimating the CPU power of the
machine.
- use that info to determine the number of voices my synth can handle
today.
or:
- specify the number voices via a startup flag (to my script, which
passes the voice-number to Pd via "-send num_voices ${VOICES}", which passes the voice-number to [clone])
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
hi,
since it's already up, i took the freedom to add a small "wish-list" of features i think would be great for PD-vanilla's next release. Almost all of these things can be done with externals, but i think they are somewhat elementary features and maybe it's not too hard to implement them in native PD.
If any of these points can be done natively already and i just haven't figured out how, please point me in the right direction:
Here's my list (i'm trying to be modest):
1.) [receive] should have a set option
right now i have to use [iem_receive] for this, but i really think that it should be PD native. [send], [send~] and [receive~] are settable, so why not [receive] as well ? i also figured, that adding a message inlet to the object wouldn't break compatibility as it has no inlet as of today.
2.) spaces in symbols/filenames etc. should be possible probably with a [list] modifier, something like:
[list makesymbol]
or even
[list makesymbol _]
(where "_" would be a settable separator, space by default).
i even figured a way to do this with vanilla objects (see attached patch "tosymbol_example.pd"). but it seems awkward and unnecessarily complicated to do it like this, would be much nicer to have an option for this much needed feature in a more direct way.
right now, my external helpers are [mergefilename] or [l2s]
3.) [closebang]
would be very useful for automated state/preset saving etc.
atm i'm using iemguts' [closebang], but it only works in abstractions. good enough for my needs, but also not vanilla ...
4.) a position outlet for [readsf~], signal or message
would be great in conjunction with GEM, to sync a video to an audio file without having to use up RAM for this. the rawness of [readsf~] is ok, but since day 1 i was missing a play-position-info feature.
5.) while we're at it: a speed flag for [readsf~] ?
6.) a drag and drop option
IOhannes made a .tcl plugin that I'm using, that at least allows DND for opening PD files when dropped onto the PD window. would be great to have that natively, too.
But what I'm missing most is somthing like this:
drop a file (i.e. a soundfile) onto a window (or even better, a designated spot, like a canvas) and receive the file's full name either from a [netreceive] object with a fixed port number, or from a settable [receive] object.
maybe it can already be done, but my TCL knowledge is nil, probably somebody on this list can point me to an "easy" solution ?
7.) better or more verbose tutorials for:
TABSEND~ / TABRECEIVE~ GRAPH-ON-PARENT / NAMECANVAS
8.) some GUI stuff i am missing and the externals i am using so far:
knob ---> mknob (moonlib) image toggle/display etc. ---> iem_image (iemgui) popup menu ---> menubutton (tof)
=======================================================================
thanks a lot for your attention !
all the best to you all, looking forward to PD 0.48, whatever it will bring !
best
oliver
On 10/01/17 14:46, oliver wrote:
4.) a position outlet for [readsf~], signal or message
You can use [timer] for this, as [readsf~] is constant speed.
(I tried a complicated [fexpr~]-based solution with integrated wrapping to avoid getting stuck after some minutes, but it drifted badly from clock time due to accumulated rounding errors - Pd's clocks are much more accurate and simpler to use too.)
IOhannes m zmölnig wrote:
On 01/10/2017 03:46 PM, oliver wrote:
IOhannes made a .tcl plugin that I'm using, that at least allows DND for opening PD files when dropped onto the PD window. would be great to have that natively, too.
why?
you're right, the plugin itself is well working and easy to implement, so actually no real need for a native thingy.
in general, i think that those little helpers (drag and drop features etc.) would lower the bar for new people to dive into the great PD world. a little convenience in the workflow doesn't hurt.
but i wanted to ask you anyway, if a slight modification of your code to provide such a thing (dropping a soundfile onto a PD window and have it's name output somewhere) would be a big deal or not.
i guess not, but i know i can't do it. at least not easily ;-)
best
oliver
Hello,
For 2) Is it helpful ? : http://markmail.org/message/4rre3i3hcci54m7j ++
Jack
Le 10/01/2017 à 15:46, oliver a écrit :
hi,
since it's already up, i took the freedom to add a small "wish-list" of features i think would be great for PD-vanilla's next release. Almost all of these things can be done with externals, but i think they are somewhat elementary features and maybe it's not too hard to implement them in native PD.
If any of these points can be done natively already and i just haven't figured out how, please point me in the right direction:
Here's my list (i'm trying to be modest):
1.) [receive] should have a set option
right now i have to use [iem_receive] for this, but i really think that it should be PD native. [send], [send~] and [receive~] are settable, so why not [receive] as well ? i also figured, that adding a message inlet to the object wouldn't break compatibility as it has no inlet as of today.
2.) spaces in symbols/filenames etc. should be possible probably with a [list] modifier, something like:
[list makesymbol]
or even
[list makesymbol _]
(where "_" would be a settable separator, space by default).
i even figured a way to do this with vanilla objects (see attached patch "tosymbol_example.pd"). but it seems awkward and unnecessarily complicated to do it like this, would be much nicer to have an option for this much needed feature in a more direct way.
right now, my external helpers are [mergefilename] or [l2s]
3.) [closebang]
would be very useful for automated state/preset saving etc.
atm i'm using iemguts' [closebang], but it only works in abstractions. good enough for my needs, but also not vanilla ...
4.) a position outlet for [readsf~], signal or message
would be great in conjunction with GEM, to sync a video to an audio file without having to use up RAM for this. the rawness of [readsf~] is ok, but since day 1 i was missing a play-position-info feature.
5.) while we're at it: a speed flag for [readsf~] ?
6.) a drag and drop option
IOhannes made a .tcl plugin that I'm using, that at least allows DND for opening PD files when dropped onto the PD window. would be great to have that natively, too.
But what I'm missing most is somthing like this:
drop a file (i.e. a soundfile) onto a window (or even better, a designated spot, like a canvas) and receive the file's full name either from a [netreceive] object with a fixed port number, or from a settable [receive] object.
maybe it can already be done, but my TCL knowledge is nil, probably somebody on this list can point me to an "easy" solution ?
7.) better or more verbose tutorials for:
TABSEND~ / TABRECEIVE~ GRAPH-ON-PARENT / NAMECANVAS
8.) some GUI stuff i am missing and the externals i am using so far:
knob ---> mknob (moonlib) image toggle/display etc. ---> iem_image (iemgui) popup menu ---> menubutton (tof)
=======================================================================
thanks a lot for your attention !
all the best to you all, looking forward to PD 0.48, whatever it will bring !
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Jack wrote:
Hello,
For 2) Is it helpful ? : http://markmail.org/message/4rre3i3hcci54m7j ++
Jack
hi, yes, that's a similar approach to what i found as a private solution for this problem.
but my point is:
IMHO something like spaces in symbols or filenames shouldn't be a problem in the first place. it should be a "no-brainer" ;-)
i'm not saying MAX is much nicer in this regard, but the solutions are easier to achieve. usually you overcome this problem on each platform by putting quotes around the message you want to define as a symbol. i think that should be natively possible in PD as well.
your abstraction is very well designed and accomplished, but it needs quite some PD knowledge and patching skills to do it. nothing for starters.
i know that the wizards can do that. i was worrying about the noobs. (what i once was as well)
best
oliver
This abstraction is not perfect (I have to finish it to remove a bug), but it can help in certain circumstance. ++
Jack
Le 10/01/2017 à 20:48, oliver a écrit :
Jack wrote:
Hello,
For 2) Is it helpful ? : http://markmail.org/message/4rre3i3hcci54m7j ++
Jack
hi, yes, that's a similar approach to what i found as a private solution for this problem.
but my point is:
IMHO something like spaces in symbols or filenames shouldn't be a problem in the first place. it should be a "no-brainer" ;-)
i'm not saying MAX is much nicer in this regard, but the solutions are easier to achieve. usually you overcome this problem on each platform by putting quotes around the message you want to define as a symbol. i think that should be natively possible in PD as well.
your abstraction is very well designed and accomplished, but it needs quite some PD knowledge and patching skills to do it. nothing for starters.
i know that the wizards can do that. i was worrying about the noobs. (what i once was as well)
best
oliver
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2017-01-05 13:55 GMT-02:00 Miller Puckette msp@ucsd.edu:
And another use case - non-real-time (batch) audio rendering as in csound where you just allocate instances as you need 'em. This definitely needs doing.
recently, I was trying to figure out a way of doing a simple SuperCollider recursion code in Pd
"var function = { |i| var osc = {SinOsc.ar(i, function.(i - 1))}; if(i >= 160, osc, 0)}; {function.(170) ! 2}.play)"
And the idea (instead of dynamic patching) was to have a method for [clone] to change the number of instances.
yeah, definitely needs doing ;)
cheers M
On Thu, Jan 05, 2017 at 04:45:15PM +0100, IOhannes m zmoelnig wrote:
On 2017-01-01 21:32, Miller Puckette wrote:
I can take on a larger list of smaller changes. The major changes I want to try to put in this release are as follows:
here's another one that emerged from my wishlist, after the few mentions of [clone] in the last days:
add a method to clone to change the number of instances. i understand that this is not a realtime operation, but a use-case could look like:
- at startup, run a profiling patch estimating the CPU power of the
machine.
- use that info to determine the number of voices my synth can handle
today.
or:
- specify the number voices via a startup flag (to my script, which
passes the voice-number to Pd via "-send num_voices ${VOICES}", which passes the voice-number to [clone])
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list