You can submit edited patches to the bug tracker on the sourceforge page [http://sourceforge.net/tracker/?group_id=55736&atid=478070 direct link].
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
Seriously, they are the most functional and useable get-started-out-of-box things to represent Pd around, and they are not in Pd-extended!
~Kyle
On 6/8/07, patrice colet megalegoland@yahoo.fr wrote:
Le vendredi 08 juin 2007 à 21:35 +0200, Georg Holzmann a écrit :
And you are invited to help - cleaning up some patches, adding comments, include out-of-the-box examples,
Where would I submit corrected files?
Hallo!
You can submit edited patches to the bug tracker on the sourceforge page [http://sourceforge.net/tracker/?group_id=55736&atid=478070 direct link].
Yes, or if you have a useful bundle of patches that work out of the box with pd extended just send them to me or to the list and I will add them to the abstractions of pd extended ...
Or you could of course also correct some of the already included abstractions (which are quite a lot) - because most of the don't work out of the box with all the externals !
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
Everyone could integreate them to her/his own pd-extended using a simple "-path flatspace", as AFAIK everything netpd uses is already there and people not using pd-extended wouldn't have tons of "import: couldn't create" error messages.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo!
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
Everyone could integreate them to her/his own pd-extended using a simple "-path flatspace", as AFAIK everything netpd uses is already there and people not using pd-extended wouldn't have tons of "import: couldn't create" error messages.
No, zexy and iemlib is not in flatspace ...
LG Georg
Hallo, Georg Holzmann hat gesagt: // Georg Holzmann wrote:
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
Everyone could integreate them to her/his own pd-extended using a simple "-path flatspace", as AFAIK everything netpd uses is already there and people not using pd-extended wouldn't have tons of "import: couldn't create" error messages.
No, zexy and iemlib is not in flatspace ...
You got me as a non-pd-ext-user. Well, then just add zexy and iem to the path. My point is: So far, the standard way to change the path or load libs is through the Preferences or with [declare]. This works on every distribution of Pd. [import] is an alternative way to do it with an external, which only works, if that external is available and if the externals/libraries are installed in the way, pd-extended installes them, that is, the paths are named according to the names pd-extended gave them. (Correct me, if I'm wrong here.)
So to activate netpd's needed externals, one can either do it in a way that works everywhere or one could depend on [import] and a certain path layout.
I have the impression, that the netpd community currently doesn't want to depend on the second, but instead leaves it to the users to set up their environment in a way, that zexy and maxlib objects are available.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, 2007-06-09 at 17:24 +0200, Frank Barknecht wrote:
So to activate netpd's needed externals, one can either do it in a way that works everywhere or one could depend on [import] and a certain path layout.
I have the impression, that the netpd community currently doesn't want to depend on the second, but instead leaves it to the users to set up their environment in a way, that zexy and maxlib objects are available.
right, since there is no way that will work for sure on any box, i think it's the safer choice to let the user do all the work.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own.
These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!).
In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way?
If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone?
~Kyle
On 6/9/07, Enrique Erne pd@mild.ch wrote:
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site?
The largest challenge with this idea is the extra machinery for synchronization between netpd elements. However, this machinery is ideal for implementing a preset system for the instruments, so that could be very nice.
~Kyle
On 6/9/07, Kyle Klipowicz kyleklip@gmail.com wrote:
Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own.
These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!).
In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way?
If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone?
~Kyle
On 6/9/07, Enrique Erne pd@mild.ch wrote:
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
--
---- -----
On Jun 9, 2007, at 4:11 PM, Kyle Klipowicz wrote:
On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions,
there is no tarball. and if there would be it would be not up to date within short time.
of will I have to go to each description page on the netpd site?
i wouldn't do that because there are not all instruments available. and maybe it's not the newest version. somebody could make an archive of his current netpd directory and send it to you.
or we check the idea of adding only netpd to the cvs and so everybody can get it online.
if people start writing patches using pd-extended and all it's externals we will probably have many new external related and os specific bugs and patches that wont work on everybody's system.
The largest challenge with this idea is the extra machinery for synchronization between netpd elements.
why do you want a extra machinery .. there is synchronization from a patch called master.pd (global metro)
However, this machinery is ideal for implementing a preset system for the instruments, so that could be very nice.
there has been a state saving system for a long time and on it a preset administrator (which i just fixed yesterday)
~Kyle
ciao eni
On 6/9/07, Kyle Klipowicz kyleklip@gmail.com wrote:
Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own.
These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!).
In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way?
If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone?
~Kyle
On 6/9/07, Enrique Erne pd@mild.ch wrote:
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
--
---- -----
--
---- -----
http://perhapsidid.wordpress.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Eni, thanks for responding~
On 6/10/07, Enrique Erne pd@mild.ch wrote:
i wouldn't do that because there are not all instruments available. and maybe it's not the newest version. somebody could make an archive of his current netpd directory and send it to you.
It would be great if I could get one, since I just tried logging into netpd and no one was on! It is really neat though, from what I saw. The IRC-ish client is very snazzy (but could use the spaces as I gathered from the logs). I'm really excited to be on when there are other users to see how it all works!
if people start writing patches using pd-extended and all it's externals we will probably have many new external related and os specific bugs and patches that wont work on everybody's system.
I am not meaning that people will add to netpd from Pd-extended. Rather, it would be neat to 'steal' the great functional modules that are in netpd and use them as standalone modules for rapid building of non-netpd patches. Say, if a person has been using Reason for a few years, but wants to upgrade. The netpd abstractions that I've looked over on the netpd site seem to be fairly strait forward in GUI and purpose that a Reason Seasoned (couldn't resist the rhyme) user could take these modules and build their own patches with them, APART from netpd.
Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction?
I wasn't suggesting that NETPD the whole community/project be consumed into the Pd-extended distro so that changes made within Pd-extended would influence netpd. However, some sort of Pd-daemon would be neat if it could automatically update the cvs every time a netpd patch has been updated (and possible cleared for errors/bugs), so that the distro is constantly in sync with the netpd community action.
The largest challenge with this idea is the extra machinery for synchronization between netpd elements.
why do you want a extra machinery .. there is synchronization from a patch called master.pd (global metro)
I hope that this makes sense now after reading above. Since the objects will be decontextualized from the group composition efforts of netpd the community, it would be necessary to use some sort of dummy system to get the objects to still work with each other...at least I think so. I haven't gotten a hold of them yet to try. I guess I can get some from the netpd site until I actually get a hold of some members online using it.
However, this machinery is ideal for implementing a preset system for the instruments, so that could be very nice.
there has been a state saving system for a long time and on it a preset administrator (which i just fixed yesterday)
So I'm meaning that for newbies using the netpd abstractions on their lonesome, trying to figure out Pd, they could use this state saving as a way to document their explorations and subsequent compositions. If they got into it, they could discover the online world of netpd. If not, at least they had a great time learning Pd using the awesome instruments provided from netpd and ported to being fairly autonomous abstractions for Pd-extended.
Any more thoughts?
~Kyle
Hallo!
I am not meaning that people will add to netpd from Pd-extended. Rather, it would be neat to 'steal' the great functional modules that are in netpd and use them as standalone modules for rapid building of non-netpd patches. Say, if a person has been using Reason for a few years, but wants to upgrade. The netpd abstractions that I've looked over on the netpd site seem to be fairly strait forward in GUI and purpose that a Reason Seasoned (couldn't resist the rhyme) user could take these modules and build their own patches with them, APART from netpd.
Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction?
Yes, that's also what I meant - this would be nice ...
I don't know who is the maintainer of the netpd community - maybe someone could maintain these objects in CVS ? (then this could be also used as a central place for checking out the latest patches ...) If it is not changing too much I can also add them to CVS ...
LG Georg
hi Georg
On Jun 11, 2007, at 9:25 AM, Georg Holzmann wrote:
I am not meaning that people will add to netpd from Pd-extended. Rather, it would be neat to 'steal' the great functional modules that are in netpd and use them as standalone modules for rapid building of non-netpd patches. Say, if a person has been using Reason for a few years, but wants to upgrade. The netpd abstractions that I've looked over on the netpd site seem to be fairly strait forward in GUI and purpose that a Reason Seasoned (couldn't resist the rhyme) user could take these modules and build their own patches with them, APART from netpd.
Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction?
Yes, that's also what I meant - this would be nice ...
I don't know who is the maintainer of the netpd community - maybe
hehe ... well who is the maintainer of the puredata community ? the netpd-wiki is open. everyone can edit and add to the wiki and many did so.
maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version.
someone could maintain these objects in CVS ? (then this could be also used as a central place for checking out the latest patches ...)
well not for netpd itself.
- if they have to be standalone i guess they wouldn't work anymore
with netpd
- if you would include the original patches then i'd rather
add only netpd and let the user download the newest patches over netpd.
- an other disadvantage of the cvs (please correct me if i'm wrong)
one has to be pd-dev to make changes in cvs, that means not everybody could add netpd-patches to the central place ...
also in my eyes the netpd wiki is _not_ the central place to add patches. it is only a public place to show some patches or write documentation for it.
i think the central place to add netpd-patches is netloading patches in _creator.pd .
btw. mMm is working standalone but unlike a netpd-instrument it doesn't use the usual netpd-abstractions.
so far... well i have to go back to work and would like to know romans opinion about this topic.
cheers eni
Hallo!
maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version.
you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ...
But I don't know much about netpd so I migth be wrong ...
LG Georg
After playing around a little bit with netpd over the past few days, I think that it would be possible to write a dummy _controller.pd that would allow a user to have the netpd experience without an internet connection. Maybe this could be included with a pd-extended netpd library (as well as the REAL controller) so that users could use the modules for their own purposes beyond the collective jam session.
Also to Eni, Roman and whoever else is involved: I'm totally impressed by netpd guys! This is a very usable piece of software and the community aspect is very welcoming. Keep up the good work!
~Kyle
On 6/12/07, Georg Holzmann grhPD@gmx.at wrote:
Hallo!
maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version.
you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ...
But I don't know much about netpd so I migth be wrong ...
LG Georg
i'm glad you like it. was it hard to install?
if i'd maintain it into cvs first thing i would do is add plain/basic netpd. then i would add some patches to the 2 directories netpd/patches and netpd/abs.
btw. if you disconnect the chat from the netpd server everything works locally. it opens a bridge from [s netpd-broadcast] to [r netpd-receive]
i want to know romans opnion about (netpd)U(Pd-extended)
On Jun 12, 2007, at 6:38 PM, Kyle Klipowicz wrote:
After playing around a little bit with netpd over the past few days, I think that it would be possible to write a dummy _controller.pd that would allow a user to have the netpd experience without an internet connection. Maybe this could be included with a pd-extended netpd library (as well as the REAL controller) so that users could use the modules for their own purposes beyond the collective jam session.
Also to Eni, Roman and whoever else is involved: I'm totally impressed by netpd guys! This is a very usable piece of software and the community aspect is very welcoming. Keep up the good work!
~Kyle
On 6/12/07, Georg Holzmann grhPD@gmx.at wrote:
Hallo!
maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version.
you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ...
But I don't know much about netpd so I migth be wrong ...
LG Georg
--
---- -----
http://perhapsidid.wordpress.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Tue, 2007-06-12 at 11:38 -0500, Kyle Klipowicz wrote:
After playing around a little bit with netpd over the past few days, I think that it would be possible to write a dummy _controller.pd that would allow a user to have the netpd experience without an internet connection. Maybe this could be included with a pd-extended netpd library (as well as the REAL controller) so that users could use the modules for their own purposes beyond the collective jam session.
this is very easy to reach and already implemented in _chat.pd. when you go offline, your netpd works offline (see subpatch [pd netpd]/[pd chat]/[pd offline] in _chat.pd).
Also to Eni, Roman and whoever else is involved: I'm totally impressed by netpd guys! This is a very usable piece of software and the community aspect is very welcoming. Keep up the good work!
thanks! nice to hear.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Tue, 2007-06-12 at 15:17 +0200, Georg Holzmann wrote:
Hallo!
maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version.
you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ...
But I don't know much about netpd so I migth be wrong ...
two prerequisites must be fullfilled in order to work netpd-patches in standalone mode in pd-extended:
a) netpd-abs need to be included as well
b) an additional patch, that imitates the netpd-server would be needed. basically that patch would just be:
[r netpd-broadcast]
|
| [r netpd-send]
| |
| [list split 1]
| /
| ________/
|/
[s netpd-receive]
(yeah, in ascii art you can have segmented patch cords ;-) )
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Great! This seems easy enough. I think that this is the simplest solution for now anyway. Eventually being able to separately use modules and even create alternate GUIs for them would be nice too. Of course, I think that the GUIs in netpd are one of the most attractive aspects for new users (and people like me who appreciate thoughtful design).
So it sounds like Georg is offering to add this stuff to CVS. What are the major decisions then that need to be made to get this thing rolling? I've got these:
- Decide whether or not to take a static sampling of the netpd
community at a certain point, or keep this updated fluidly like netpd itself.
- Decide if the files will emulate netpd by mimicking the
_controller.pd patch and server-side communications, or if they will be rewritten in another way.
Find the best way to keep the files checked in to cvs.
Actually check it in.
Test it out.
Fix errors.
I think that using the namespace features of Pd-extended will be very nice if one would wish to run both the netpd online community, as well as the independent Pd-extended version.
Any thoughts or additions to this quick list of steps to be done?
~Kyle
On 6/14/07, Roman Haefeli reduzierer@yahoo.de wrote:
On Tue, 2007-06-12 at 15:17 +0200, Georg Holzmann wrote:
Hallo!
maybe some chosen patches could be converted to work standalone, but it would be lots of work ... and introduce new bugs. some systems like the fx-library system for the mixer were specially developed that different users can develop effects without touching the mixer itself. somehow that wouldn't make sense in a standalone version.
you don't have to convert them - you could add them as they are, so they would work with netpd and are included in pd-extended ...
But I don't know much about netpd so I migth be wrong ...
two prerequisites must be fullfilled in order to work netpd-patches in standalone mode in pd-extended:
a) netpd-abs need to be included as well
b) an additional patch, that imitates the netpd-server would be needed. basically that patch would just be:
[r netpd-broadcast] | | [r netpd-send] | | | [list split 1] | / | ________/ |/ [s netpd-receive]
(yeah, in ascii art you can have segmented patch cords ;-) )
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Mon, 2007-06-11 at 09:25 +0200, Georg Holzmann wrote:
Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction?
Yes, that's also what I meant - this would be nice ...
I don't know who is the maintainer of the netpd community - maybe someone could maintain these objects in CVS ? (then this could be also used as a central place for checking out the latest patches ...) If it is not changing too much I can also add them to CVS ...
there is no maintainer for what the community produces. rather is the community maintaining itself. to be more specifically, i think, what could be interesting to be included into pd-extended are mainly the dsp parts of many patches (e.g drums, basssynths, etc.), since these parts are relatively easy to extract and separate from an existing netpd patch. and i think also, that these parts can be used in a general way, whereas other parts (sequencer stuff, mixers and others) are very interwoven with netpd and might not be used in that general manner outside of the netpd context. that is why i'd say it would make sense to focus on the dsp/synth stuff of netpd. the experience showed, that often these parts have not changed much (even at all) after the release of a netpd patch. that is why i think, there is no much need for someone maintaining that stuff in cvs (since i think that wouldn't work anyway), it just needs to be inlcuded. as i said in a previous post, it is a matter of someone porting the patches to generally usuable modules.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Mon, 2007-06-11 at 00:40 -0500, Kyle Klipowicz wrote:
Rather than reinvent the wheel, why not take the fruits of the netpd community and make them accessible to users who might just want a wikkid bassline or GOP mixer abstraction?
yeah, absolutely. as often, it is a question of someone doing the work.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sun, 2007-06-10 at 11:45 +0200, Enrique Erne wrote:
However, this machinery is ideal for implementing a preset system for the instruments, so that could be very nice.
there has been a state saving system for a long time and on it a preset administrator (which i just fixed yesterday)
which breaks the netpd presetfile syntax. we'll have to talk about this again. i don't think that a patch that has its own implementation of saving and loading presets and whose presets are not compatible with presets made the standard way should be considered as the standard tool for saving and loading presets in netpd.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sat, 2007-06-09 at 09:11 -0500, Kyle Klipowicz wrote:
On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site?
yes, i think so (unfortunately). it would be surely very useful to provide an archive of all patches. it's just that i don't know how to do it automatically, so that it doesn't need to be updated manually everyweek.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
On Sat, 2007-06-09 at 09:11 -0500, Kyle Klipowicz wrote:
On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site?
yes, i think so (unfortunately). it would be surely very useful to provide an archive of all patches. it's just that i don't know how to do it automatically, so that it doesn't need to be updated manually everyweek.
roman
ola roman
why not just make again a dummy user, and his netpd-folder would be in public_html?
greets
from stressed moritz
Good idea. There could be a script called by cron to automatically tarball this dir every week.
~Kyle
On 6/14/07, moritz erstens@gmx.ch wrote:
Roman Haefeli wrote:
On Sat, 2007-06-09 at 09:11 -0500, Kyle Klipowicz wrote:
On that tip, I'm curious if there is a tarball of all the current netpd instrument/effects/utility abstractions, of will I have to go to each description page on the netpd site?
yes, i think so (unfortunately). it would be surely very useful to provide an archive of all patches. it's just that i don't know how to do it automatically, so that it doesn't need to be updated manually everyweek.
roman
ola roman
why not just make again a dummy user, and his netpd-folder would be in public_html?
greets
from stressed moritz
good morning Kyle
i would only add the basic netpd to Pd-extended without any instrument, so that any user can get the newest version of the instruments through creator without maintaining all the instruments in cvs.
the netpd-instruments are using some basic netpd-abstractions for broadcasting, synchronizing and statesaving so they wont work without netpd anyway.
little correction: the instruments are not Graph On Parent abstractions but patches with their GUI in a subpatch named: [pd synthname-gui]
i'm pretty green about cvs. over the pasat 3 years there have been at least 10 different people writing instruments for netpd. how is this done in other projects... like pixeltango or rradical are they maintained in cvs by one person or has anybody access to change everything?
regards
eni
On Jun 9, 2007, at 3:57 PM, Kyle Klipowicz wrote:
Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own.
These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!).
In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way?
If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone?
~Kyle
On 6/9/07, Enrique Erne pd@mild.ch wrote:
I am now wondering something: why haven't these awesomely
functional
netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
--
Hallo, Enrique Erne hat gesagt: // Enrique Erne wrote:
i'm pretty green about cvs. over the pasat 3 years there have been at least 10 different people writing instruments for netpd. how is this done in other projects... like pixeltango or rradical are they maintained in cvs by one person or has anybody access to change everything?
It depends. Generally the CVS on Sourceforge has almost no access control: Everyone can overwrite everyone else's patches. It's based on trust that this doesn't happen unless with permission.
Some sub-projects are maintained by several people, like "mapping", which is Hans and Cyrille and maybe more, or "purepd" which contains patches by several people. Others are more a one-person issue, like RTC-lib.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
I like this idea quite a bit. One approach would be to separate the
synths and their GUIs into separate objects. Then people who want to
try different synths using their own controllers would have a nice
library to work with, and people who want to use on-screen interfaces
would too.
.hc
On Jun 9, 2007, at 9:57 AM, Kyle Klipowicz wrote:
Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own.
These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!).
In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way?
If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone?
~Kyle
On 6/9/07, Enrique Erne pd@mild.ch wrote:
I am now wondering something: why haven't these awesomely
functional
netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but
not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
--
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
On Sat, 2007-06-09 at 08:57 -0500, Kyle Klipowicz wrote:
Yes, what I am talking about is not to add 'netpd the whole application' to Pd-extended, but merely the modules, which are functional and quite useful on their own.
yeah, that is what i think as well.
These seem to be the best developed set of GOP objects that would be immediately understandable to those coming from the Reason/Reaktor/AudioMulch/whatever crowd, and would serve as a nice entry point to Pd even when removed from the context of internet collaborative performance (which is still a WAY cool concept, Roman!).
a netpd-patch is a patch with a gui-subpatch, that uses some netpd-abstractions and possibly some others, but usually they don't use GOP. either turning them into GOP-modules or just into abstractions, both would require at least a minimum of work (and writing some help-patches).
In the next week or so, I will start tinkering with some patches to see how well they integrate in my local Pd-extended distribution. If the go ahead is there from the netpd community, I'll try to write up a quick proposal to include these in the Pd-extended distro. Roman, how would I go about getting permission to distribute the patches in this way?
this topic was never seriously discussed and it is not clear, if and how the netpd-patches could be generally licensed. but since it is known, that a patch opened in netpd is distributed within the whole community, one can assume, that these patches are meant to be shared.
If this were to happen, would that require that the patches be maintained in cvs separate from the netpd application page? I'm pretty green at this sort of thing, but it seems like something that would be a great benefit, and which I might actually be able to help with. So please, feedback anyone?
i don't think that it is realistic to expect people to maintain there patches in cvs. and i think it is more a question of porting the patches to generally useful modules than of maintaining these modules, since i don't believe that people who made some patches for netpd will maintain the modules derived from their patches over years.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Jun 9, 2007, at 5:45 AM, Enrique Erne wrote:
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
This right here outlines the main purpose of Pd-extended: to provide
a tested and reliable package that works the same on all OSes.
Basically, I think you should pick one platform for netpd, and make
sure everything works smoothly on that one. Then worry about the rest.
Alex Quessy and I tried to run the latest version on netpd working
for a network jam last Sunday, we both failed. He got further than
me, he got some sounds out, but neither got it all working. Both of
us know quite a bit about Pd, so I am amazed that newbies get it
going (do they?).
It would very nice if it was just plug and play. It would not be
that hard to do it. I think you could spend a day on it and have it
working smoothly. It would be very worthwhile, but I think you have
already spent far more time trying to help people get it going than
it would take to fix things.
.hc
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
hello hans
On Jun 13, 2007, at 3:46 AM, Hans-Christoph Steiner wrote:
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
This right here outlines the main purpose of Pd-extended: to provide a tested and reliable package that works the same on all OSes.
Basically, I think you should pick one platform for netpd, and make sure everything works smoothly on that one. Then worry about the rest.
picking one platform for netpd is not possible. i doubt roman will change to osx ;-), people have been developing under all OS. for me there is no current pd-extended on osx 10.3.9 (right now i can't change to 10.4 or linux)
Alex Quessy and I tried to run the latest version on netpd working for a network jam last Sunday, we both failed. He got further than me, he got some sounds out, but neither got it all working.
what didn't work? that day i saw you guys in the log file.. you managed to login to netpd. unfortunately nobody was there to help you and upload the right patches. downloading all the instruments form the wiki is not ideal to start with netpd. you need at least 3 patches to get a sound: master.pd, qseq2.pd and a drummachine. things like that are not documented anywhere.
Both of us know quite a bit about Pd, so I am amazed that newbies get it going (do they?).
well they should easily manage to connect and then usually somebody gives a little intro to the netpd jungle.
at the moment only newbies on windows have a double clickable netpd package. the package on osx is currently not working because of 10.3/10.4/ppc/intel + externals . there never was a linux package so far.
It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things.
that's true. what do you suggest? what technology would be required? i think getdir would solve the whole path issue. does getdir work without [import]?
since we netload patches with openpanel it would be better to have the netpd directory not inside the .app , but it would be indise the .app if it is in the cvs right?
regards
eni
On Jun 13, 2007, at 4:10 AM, Enrique Erne wrote:
hello hans
On Jun 13, 2007, at 3:46 AM, Hans-Christoph Steiner wrote:
on one hand i would like to see netpd included in pd-extended,
but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
This right here outlines the main purpose of Pd-extended: to
provide a tested and reliable package that works the same on all
OSes. Basically, I think you should pick one platform for netpd,
and make sure everything works smoothly on that one. Then worry
about the rest.picking one platform for netpd is not possible. i doubt roman will
change to osx ;-), people have been developing under all OS. for me
there is no current pd-extended on osx 10.3.9 (right now i can't
change to 10.4 or linux)
Sorry, I should have used a different word. By "platform", I mean pd-
vanilla, pd-extended, desiredata, pd-devel, jmax, whatever. I did
not mean choose an OS. For things not supported on that platform
would have to be taken care of by the patch authors.
Alex Quessy and I tried to run the latest version on netpd working
for a network jam last Sunday, we both failed. He got further
than me, he got some sounds out, but neither got it all working.what didn't work? that day i saw you guys in the log file.. you
managed to login to netpd. unfortunately nobody was there to help
you and upload the right patches. downloading all the instruments form the wiki is not ideal to start
with netpd. you need at least 3 patches to get a sound: master.pd, qseq2.pd and
a drummachine. things like that are not documented anywhere.
A bunch of things, missing objects, crashes, trouble uploading
patches. I could only get patches to work when Alex uploaded them
from his GNU/Linux machine. I gave up when I got things running, but
no instruments would show up to select in the qsec2 scroll bars. I
could tweak the sequences that Alex had made.
Both of us know quite a bit about Pd, so I am amazed that newbies
get it going (do they?).well they should easily manage to connect and then usually somebody
gives a little intro to the netpd jungle.at the moment only newbies on windows have a double clickable netpd
package. the package on osx is currently not working because of
10.3/10.4/ppc/intel + externals . there never was a linux package
so far.It would very nice if it was just plug and play. It would not be
that hard to do it. I think you could spend a day on it and have
it working smoothly. It would be very worthwhile, but I think you
have already spent far more time trying to help people get it
going than it would take to fix things.that's true. what do you suggest? what technology would be
required? i think getdir would solve the whole path issue. does
getdir work without [import]?
You can load getdir like this: [ggee/getdir]. But this is what I
mean by choose a platform. Pd-extended provides getdir in the same
place on all platforms. If you used pd-vanilla, you would then need
to bundle getdir for each platform, and so on and so forth.
since we netload patches with openpanel it would be better to have
the netpd directory not inside the .app , but it would be indise
the .app if it is in the cvs right?
I think it should not be too hard to make netpd double-clickable with
no extra setup at all (setting .pdrc, etc.) without embedding it into
it's own Pd install. The key is just trying it on other people's
machines, and finding the common access methods that work across OSes.
.hc
regards
eni
There is no way to peace, peace is the way. -A.J. Muste
On Wed, 2007-06-13 at 11:21 -0400, Hans-Christoph Steiner wrote:
I think it should not be too hard to make netpd double-clickable with
no extra setup at all (setting .pdrc, etc.) without embedding it into
it's own Pd install.
but this works smoothly and i think it is the only option, so that non-pd-users are willing install netpd.
The key is just trying it on other people's
machines, and finding the common access methods that work across OSes.
again, can you elaborate that a bit more?
how can the startup-script be edited by a double click installer in a manner, that it works with every pd-installation?
the main problem i see here, that (in contrary to other programing languages, if pd is considered as a programing language) pd lacks any feedback about loaded pathes and externals. if there would be a way to check within pd, if a certain external was loaded, a netpd-user would at least know, why it does not work as expected. also for the other issue with the netpd-path, using 'getdir' would be just a workaround, but not the solution for the problem (since using additional externals in an environment like pd increases the chance of having troubles anyway).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hello Eni, Enrique Erne a écrit :
does getdir work without [import]?
regards
eni
Why wouldn't it work without [import]? I've got it working so fine without the help of any ohter stuff than vanilla. Pk
On Jun 14, 2007, at 3:08 PM, Patco wrote:
does getdir work without [import]?
Why wouldn't it work without [import]? I've got it working so fine without the help of any ohter stuff than vanilla. Pk
ah i am not sure about pd-extended's flatspace. when to use [ggee/getdir], [import ggee], -lib ggee, or just [getdir]
Hallo!
ah i am not sure about pd-extended's flatspace. when to use [ggee/getdir], [import ggee], -lib ggee, or just [getdir]
If getdir is in ggee, then you can use
[ggee/getdir] or [import ggee] and [getdir] or -lib ggee and [getdir]
LG Georg
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote:
On Jun 9, 2007, at 5:45 AM, Enrique Erne wrote:
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
on one hand i would like to see netpd included in pd-extended, but not on cost of the current package. it is important that netpd and all patches work on linux, osx and windows.
if people start to write netpd patches with pd-extended and use many externals i'm afraid we are going to have instrument that work on one os and maybe not on the other. netpd would also be a great system to find os-specific bugs :-)
This right here outlines the main purpose of Pd-extended: to provide
a tested and reliable package that works the same on all OSes.
Basically, I think you should pick one platform for netpd, and make
sure everything works smoothly on that one. Then worry about the rest.
hm, that is what netpd basically does: pd-vanilla, zexy, maxlib, that's it. these work quite the same on all os/platforms and i think also in pd-extended for every os/platform.
Alex Quessy and I tried to run the latest version on netpd working
for a network jam last Sunday, we both failed. He got further than
me, he got some sounds out, but neither got it all working. Both of
us know quite a bit about Pd, so I am amazed that newbies get it
going (do they?).
this might be rather due to bad documentation than difficulty of installing netpd. newbies often just download pd-netpd for win or osx and that works just out of the box.
It would very nice if it was just plug and play. It would not be
that hard to do it. I think you could spend a day on it and have it
working smoothly. It would be very worthwhile, but I think you have
already spent far more time trying to help people get it going than
it would take to fix things.
hm....can you elaborate a bit more what you mean by 'fixing' stuff? i know there are some drawbacks while installing netpd and i would sure fix them, if i knew how to do it:
a) the user needs to add '-path /path/to/netpd/abs' to his/her startup script. i'd love to get rid of this, but i don't see a way, since [declare -path netpd/abs] does only work withing the patch, but not for the whole pd-instance.
b) the user needs to set the path of the netpd-folder in 'netpd-settings' (see appropriate button in chat-window). since the 'open'-message to 'pd' is relative to pd's start location and NOT relative to the patch's location, the user needs to set it manually (if not using the pd-netpd-package), because there is no way to get the start-location in pd. since i am sure, that the actual behaviour of the 'open'-message doesn't make any sense at all, i hope it will be changed to 'relative to the patch' in the future. if not, i might consider using 'getdir' to overcome this problem.
i think these undesired, but atm necessary user interactions are the main cause for any troubles while installing netpd and i assume, these were the reason, why you and a.quessy had troubles installing netpd. have you better ideas to overcome these problems?
roman
.hc
Yes, would be nice - someone would have to integrate them to pd-extended (using [import] and etc.) ...
are you talking about basic netpd or netpd & all the instruments...
basic netpd is written by Roman Haefeli all the instruments have at least 10 different authors.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
'You people have such restrictive dress for women,’ she said,
hobbling away in three inch heels and panty hose to finish out
another pink-collar temp pool day. - “Hijab Scene #2", by Mohja Kahf
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote:
Alex Quessy and I tried to run the latest version on netpd working
for a network jam last Sunday, we both failed. He got further than
me, he got some sounds out, but neither got it all working. Both of
us know quite a bit about Pd, so I am amazed that newbies get it
going (do they?).
not, that kyle is a pd-newbie, but sure a netpd-newbie:
http://lists.puredata.info/pipermail/pd-list/2007-06/051021.html
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote:
It would very nice if it was just plug and play. It would not be
that hard to do it. I think you could spend a day on it and have it
working smoothly. It would be very worthwhile, but I think you have
already spent far more time trying to help people get it going than
it would take to fix things.
reading that post a second time, i feel somehow insulted by your assumption, that i consciously do not fix things, that simply could be fixed spending a day for them. so, please tell me, what do you think needs to be fixed?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Jun 14, 2007, at 1:07 PM, Roman Haefeli wrote:
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote:
It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things.
reading that post a second time, i feel somehow insulted by your assumption, that i consciously do not fix things, that simply could be fixed spending a day for them. so, please tell me, what do you think needs to be fixed?
Certainly no insult of any kind was intended. I was just quite
frustrated by the experience. We were having a network jam at the
end of the NIME conference, a few of us wanted to use netpd. But
only Alexandre was able to get it running.
Please don't take my comments to be saying something bad about your
skills or the work you put it. It can be a hard problem to solve,
getting everything running smoothly, but it is certainly possible.
You have been very good at providing help for people to get it up and
running. I'd just like to see netpd get to the point where you can
spend less time helping people get it running and more time improving
things.
In the general terms, I think it should be quite possible to make
netpd "just work" on any Pd-extended install with the user just
opening a patch in Pd. If you want to base netpd on pd-vanilla, then
you'll need to provide any externals that are needed for the various
platforms.
As for my problem at the NIME jam, I wasn't really able to pinpoint
the problem. But I'll work thru it with you sometime. Basically,
take a machine that doesn't have netpd running, take a fresh,
untouched Pd install, and try running netpd. For each step the stops
it from running, try to fix it without changing the environment or
the Pd startup settings.
.hc
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
On Mon, 2007-06-18 at 19:05 -0400, Hans-Christoph Steiner wrote:
On Jun 14, 2007, at 1:07 PM, Roman Haefeli wrote:
On Tue, 2007-06-12 at 21:46 -0400, Hans-Christoph Steiner wrote:
It would very nice if it was just plug and play. It would not be that hard to do it. I think you could spend a day on it and have it working smoothly. It would be very worthwhile, but I think you have already spent far more time trying to help people get it going than it would take to fix things.
reading that post a second time, i feel somehow insulted by your assumption, that i consciously do not fix things, that simply could be fixed spending a day for them. so, please tell me, what do you think needs to be fixed?
Certainly no insult of any kind was intended. I was just quite
frustrated by the experience. We were having a network jam at the
end of the NIME conference, a few of us wanted to use netpd. But
only Alexandre was able to get it running.
hm, i am sorry about that.
Please don't take my comments to be saying something bad about your
skills or the work you put it. It can be a hard problem to solve,
getting everything running smoothly, but it is certainly possible.
You have been very good at providing help for people to get it up and
running. I'd just like to see netpd get to the point where you can
spend less time helping people get it running and more time improving
things.
as i said, i know the problems (if they could be considered as problems), but didn't find a way around them.
In the general terms, I think it should be quite possible to make
netpd "just work" on any Pd-extended install with the user just
opening a patch in Pd. If you want to base netpd on pd-vanilla, then
you'll need to provide any externals that are needed for the various
platforms.
netpd actually should 'just' work with any pd-installation, though three points are critical:
- having the right externals loaded (that is: zexy, maxlib, iemmatrix,
iemlib1, iemlib2, iem_t3_lib)
- having the correct netpd-path in the netpd-settings dialog (this one
annoys me most, because it is due to the 'open-message-path-is-relative-to-pd's-startlocation'-problem [to mention this problem again])
-having netpd/abs in the pathes
if these settings are correct and netpd is still not working, then something is definitely wrong.
luckily just yesterday, i had a (very simple) idea, for which i waited for years: instead of opening the netpd-patches with the (for me) inconvenient 'open'-message, i want to load them as abstractions. this has the BIG advantage, that i can specify the location of a patch (now abstraction) relative to the parent patch (creator in this case). by doing that i can get rid of the very unwanted 'netpd-path' setting. AND this has a very nice side effect: when all patches are actually the same patch, i can add a search patch with only one [declare], that is valid for all loaded netpd-patches (now abstractions). in short: in future versions of netpd there will be no need for 'netpd-path' and for a -path flag anymore. there is one critical point left: having to have loaded the right externals. with [declare], each netpd-patch can define for itself, what it wants to have loaded. that means, the only thing, a user will have to care, is to have installed the needed externals (which is the case anyway in extended)
i actually don't have time to implement all these changes and afaik the actual stable release of pd-extended is based on 0.39, which lacks [declare]. but when pd-extended switches to 0.40 and i'll have made the necessary changes, things will be hopefully much easier than today for eveveryone, the pd-extended users and pd-vanilla/external users.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On 6/18/07, Roman Haefeli reduzierer@yahoo.de wrote:
luckily just yesterday, i had a (very simple) idea, for which i waited for years: instead of opening the netpd-patches with the (for me) inconvenient 'open'-message, i want to load them as abstractions. this has the BIG advantage, that i can specify the location of a patch (now abstraction) relative to the parent patch (creator in this case). by doing that i can get rid of the very unwanted 'netpd-path' setting. AND this has a very nice side effect: when all patches are actually the same patch, i can add a search patch with only one [declare], that is valid for all loaded netpd-patches (now abstractions). in short: in future versions of netpd there will be no need for 'netpd-path' and for a -path flag anymore. there is one critical point left: having to have loaded the right externals. with [declare], each netpd-patch can define for itself, what it wants to have loaded. that means, the only thing, a user will have to care, is to have installed the needed externals (which is the case anyway in extended)
This is great! I also like an additional feature of this method that you did not mention. When closing an instrument window, right now it will actually cause the instrument to disappear. I think that I actually inadvertantly crashed netpd a few times by doing this (since I am used to closing abstraction windows and subpatches to free visual space, but keeping them running still). So now, with this new idea, you would be able to close these windows in the normal way without it affecting netpd sessions.
Sorry if I ruined your sessions ever by doing this!!!
i actually don't have time to implement all these changes and afaik the actual stable release of pd-extended is based on 0.39, which lacks [declare]. but when pd-extended switches to 0.40 and i'll have made the necessary changes, things will be hopefully much easier than today for eveveryone, the pd-extended users and pd-vanilla/external users.
You could actually start working on Pd-0.40-extended, as it is already auto building every night!
~Kyle
On Tue, 2007-06-19 at 11:47 -0500, Kyle Klipowicz wrote:
On 6/18/07, Roman Haefeli reduzierer@yahoo.de wrote:
luckily just yesterday, i had a (very simple) idea, for which i waited for years: instead of opening the netpd-patches with the (for me) inconvenient 'open'-message, i want to load them as abstractions. this has the BIG advantage, that i can specify the location of a patch (now abstraction) relative to the parent patch (creator in this case). by doing that i can get rid of the very unwanted 'netpd-path' setting. AND this has a very nice side effect: when all patches are actually the same patch, i can add a search patch with only one [declare], that is valid for all loaded netpd-patches (now abstractions). in short: in future versions of netpd there will be no need for 'netpd-path' and for a -path flag anymore. there is one critical point left: having to have loaded the right externals. with [declare], each netpd-patch can define for itself, what it wants to have loaded. that means, the only thing, a user will have to care, is to have installed the needed externals (which is the case anyway in extended)
This is great! I also like an additional feature of this method that you did not mention. When closing an instrument window, right now it will actually cause the instrument to disappear. I think that I actually inadvertantly crashed netpd a few times by doing this (since I am used to closing abstraction windows and subpatches to free visual space, but keeping them running still).
Usually you should only see the gui of a patch, not the main patch itself (except when you are interested in seeing the internals of a certain patch). but it's true, that the patch gets closed then unintentionally, though this shouldn't crash pd. and if your pd crashes then, it doesn't harm the session at all. you can just restart pd/netpd and join the session, without the others noticing that you crashed.
So now, with this new idea, you would be able to close these windows in the normal way without it affecting netpd sessions.
yeah, true. i didn't think about this side effect yet.
Sorry if I ruined your sessions ever by doing this!!!
you certainly never did. and still if you did, nevermind, we are doing it for fun...... ;-)
i actually don't have time to implement all these changes and afaik the actual stable release of pd-extended is based on 0.39, which lacks [declare]. but when pd-extended switches to 0.40 and i'll have made the necessary changes, things will be hopefully much easier than today for eveveryone, the pd-extended users and pd-vanilla/external users.
You could actually start working on Pd-0.40-extended, as it is already auto building every night!
i think, it doesn't need any extra work to make it work in pd-0.40-extended. so it is just a matter of finding free time (aah, i a few weeks we'll have summer vacation.......yeah!)
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
netpd has been changing a lot over the last years, and things that
change a lot don't work well in Pd-extended. You get version
troubles, etc. I'd really like to see a lot of the netpd code made
into reusable objects and gathered into libs. There is lots of good
stuff there.
.hc
On Jun 8, 2007, at 5:07 PM, Kyle Klipowicz wrote:
You can submit edited patches to the bug tracker on the sourceforge page [http://sourceforge.net/tracker/?group_id=55736&atid=478070 direct link].
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
Seriously, they are the most functional and useable get-started-out-of-box things to represent Pd around, and they are not in Pd-extended!
~Kyle
On 6/8/07, patrice colet megalegoland@yahoo.fr wrote:
Le vendredi 08 juin 2007 à 21:35 +0200, Georg Holzmann a écrit :
And you are invited to help - cleaning up some patches, adding
comments, include out-of-the-box examples,Where would I submit corrected files?
--
---- -----
http://perhapsidid.wordpress.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
On Tue, 2007-06-12 at 21:42 -0400, Hans-Christoph Steiner wrote:
netpd has been changing a lot over the last years, and things that
change a lot don't work well in Pd-extended. You get version
troubles, etc.
maybe i am blind to see the obvious solution, but the main problem i see in including netpd into pd-extended is a complete different one: at least the patches and the abstraction folders need to be outside the package, since a user needs to have a writing access to these while using netpd. if netpd would be included into pd-extended, either one has to create the necessary folders him/herself, or pd-extended would create them in <whereever> (assumingly /home/user/netpd, resp. /User/npetd), which is ugly and very unconvenient, if someone doesn't have any plans to use netpd at all.
I'd really like to see a lot of the netpd code made
into reusable objects and gathered into libs.
yep. i also think this is a good idea.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Fri, 2007-06-08 at 16:07 -0500, Kyle Klipowicz wrote:
You can submit edited patches to the bug tracker on the sourceforge page [http://sourceforge.net/tracker/?group_id=55736&atid=478070 direct link].
I am now wondering something: why haven't these awesomely functional netpd object been included as abstractions within Pd-extended?!?!
because nobody included them yet. ;-)
Seriously, they are the most functional and useable get-started-out-of-box things to represent Pd around, and they are not in Pd-extended!
the question is: how should they be included? should they be included as they are now, with the gui and their dependency on the netpd-framework? or would it make more sense to strip everything off to get a working subset of abstractions, that can be used in a more flexible way? as far as i understand the concept of pd-extended as a collection of abstractions and externals (read: collection of tools/utility rather than a collection of examples), i'd vote for the latter, though that would involve a lot more work.
i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo Roman!
i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended.
I can include them if you want. If you have lots of abstraction and also want to maintain them yourself maybe its also option that you get write access to cvs ?
LG Georg
The helpfile aspect would be very much appreciated!
I think that modular is better so that people can reuse netpd elements in their own patches. Of course, being able to use the sequencers and mixer + fx would be the primary Reason (forgive the semi-pun) for newbies to adopt the objects.
~Kyle
On 6/14/07, Roman Haefeli reduzierer@yahoo.de wrote:
i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended.
roman
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Thu, Jun 14, 2007 at 11:17:57AM +0200, Roman Haefeli wrote:
the question is: how should they be included? should they be included as they are now, with the gui and their dependency on the netpd-framework? or would it make more sense to strip everything off to get a working subset of abstractions, that can be used in a more flexible way? as far as i understand the concept of pd-extended as a collection of abstractions and externals (read: collection of tools/utility rather than a collection of examples), i'd vote for the latter, though that would involve a lot more work.
i'd rather do not include the abstractions/patches myself and i'd rather do not make the decision on how they should be included. but i'd be willing to deliver stripped off abstractions with helpfiles from my own netpd-patches, so someone else could could include/organize them in pd-extended.
One thing that would be cool for us to come up with is some way to abstract the core, and gui of abstractions separately in such a way that they could be used in multiple different state saving/communication paradigms.
For example, if I could make one abstraction for the s-abstractions collection and then have the user be able to choose whether it:
- saves using sssad, has a GOP gui
- saves using memento, has a GOP gui
- integrates with netpd, has netpd style gui
This could just be a pipe dream, but then again I could never have imagined someone creating something as amazing as netpd or sssad in Pure Data alone.
Best,
Chris.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
One thing that would be cool for us to come up with is some way to abstract the core, and gui of abstractions separately in such a way that they could be used in multiple different state saving/communication paradigms.
For example, if I could make one abstraction for the s-abstractions collection and then have the user be able to choose whether it:
- saves using sssad, has a GOP gui
- saves using memento, has a GOP gui
- integrates with netpd, has netpd style gui
This could just be a pipe dream, but then again I could never have imagined someone creating something as amazing as netpd or sssad in Pure Data alone.
This is not a pipe dream, if a pipe dream is, what I guess a pipe dream is. All that would be necessary are a clean and documented interfaces for the DSP abstractions. Things like state saving, GUIs or network control then could easily be built as wrapper abstractions.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hello,
Frank Barknecht a écrit :
All that would be necessary are a clean and documented interfaces for the DSP abstractions.
Yes exactly.
Things like state saving, GUIs or network control then could easily be built as wrapper abstractions.
It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction, and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction.
salute
Hallo, Patco hat gesagt: // Patco wrote:
Hello,
Frank Barknecht a écrit :
All that would be necessary are a clean and documented interfaces for the DSP abstractions.
Yes exactly.
Things like state saving, GUIs or network control then could easily be built as wrapper abstractions.
It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction,
IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments.
and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction.
A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch.
That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...)
And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote:
Hallo, Patco hat gesagt: // Patco wrote:
Hello,
Frank Barknecht a écrit :
All that would be necessary are a clean and documented interfaces for the DSP abstractions.
Yes exactly.
Things like state saving, GUIs or network control then could easily be built as wrapper abstractions.
It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction,
IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments.
and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction.
A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch.
That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...)
And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions.
Ciao
hello frank and everyone
you just did what i wanted to do: continue this thread under a new topic. you also just said, what i wanted to say:
-pure dsp-abstraction would be the first step (guis might be made on top of them afterwards for different purposes) -every abs needs a help-patch (which i agree, that this is essential)
without designing to much, how this collection could look like, there are might some little conventions, that we could make up (these are meant as proposals):
- finding a naming scheme, maybe using a prefix like dsp_**** (similar
to the list-abs).
- using messages like 'frequency 123' to set parameters, which are
routed inside the abstraction. with such a design, only one inlet for an arbitrary number of parameters is needed.
- the helpfile should at least describe the available parameters and
their default values.
then:
kyle wrote:
Find the best way to keep the files checked in to cvs.
Actually check it in.
Test it out.
Fix errors.
what do you pd-people think?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
hello, Roman Haefeli a écrit :
then:
kyle wrote:
Find the best way to keep the files checked in to cvs.
Actually check it in.
Test it out.
Fix errors.
what do you pd-people think?
roman
It's great! We will be able to test externals that are not included into net-pd distribution, and then replace all the ugly GUIs with neat and usefull [widget]s. The _chat abstraction might be the first candidate for a lifting.
I've modified the title of this topic because I've got a question or a proposition related with a networking problem that is occuring when big files are involved. What about having a static server where we could automatically upload/download sounds and binary files?
On Fri, 2007-06-15 at 20:25 +0200, Patco wrote:
I've modified the title of this topic because I've got a question or a proposition related with a networking problem that is occuring when big files are involved. What about having a static server where we could automatically upload/download sounds and binary files?
i didn't find a (good) way yet to transmit binary files within pd. do you know of any way?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli a écrit :
On Fri, 2007-06-15 at 20:25 +0200, Patco wrote:
I've modified the title of this topic
I thought I'v modified the topic title... never mind...
because I've got a question or a proposition related with a networking problem that is occuring when big files are involved. What about having a static server where we could automatically upload/download sounds and binary files?
i didn't find a (good) way yet to transmit binary files within pd. do you know of any way?
roman
The only way I know to reload a binary file is like eni said rebooting pd, I believe that this process would decrease external devel'n'debug time and allow fast and clean updates.
On Fri, 2007-06-15 at 21:17 +0200, Patco wrote:
Roman Haefeli a écrit :
On Fri, 2007-06-15 at 20:25 +0200, Patco wrote:
I've modified the title of this topic
I thought I'v modified the topic title... never mind...
because I've got a question or a proposition related with a networking problem that is occuring when big files are involved. What about having a static server where we could automatically upload/download sounds and binary files?
i didn't find a (good) way yet to transmit binary files within pd. do you know of any way?
roman
The only way I know to reload a binary file is like eni said rebooting
what do you mean by a binary file here? do you mean the pd-executable?
pd, I believe that this process would decrease external devel'n'debug time and allow fast and clean updates.
sorry, i cannot quite follow what you mean. you mean a system, that does not only share and synchronize patches, but also soundfiles and externals, so that when i use a certain file in my patch, that file get's uploaded to you? or are you specifically talking about executables and externals?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
without designing to much, how this collection could look like, there are might some little conventions, that we could make up (these are meant as proposals):
- finding a naming scheme, maybe using a prefix like dsp_**** (similar
to the list-abs).
I think, this might be done later with a simple directory-prefix. If the help-files themselves use the objects without any dir-prefix, then the name could be decided later and they would still be useable with standard methods of setting only the -path.
I didn't use a directory prefix, but instead a hardcoded prefix for [list]-abs mostly because many of them are impossible to use without the prefix anyways since they nameclash with existing objects like [list-moses] vs. [moses]. So "import list" doesn't make any sense for them. But for the dsp-collection I think, a directory prefix would make sense.
- using messages like 'frequency 123' to set parameters, which are
routed inside the abstraction. with such a design, only one inlet for an arbitrary number of parameters is needed.
Yes, that could be a kind of "good practice" recommendation. I do this in my personal abstractions a lot, where I now use the attached "dispatcher" to automate the creation of the necessary [route frequency] and [s $0-frequency] chains plus a tiny help-feature. (Requires pd-0.40 and up because of $1-$2)
- the helpfile should at least describe the available parameters and
their default values.
Yes++.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Jun 15, 2007, at 3:08 PM, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
without designing to much, how this collection could look like, there are might some little conventions, that we could make up (these are meant as proposals):
- finding a naming scheme, maybe using a prefix like dsp_****
(similar to the list-abs).
I think, this might be done later with a simple directory-prefix. If the help-files themselves use the objects without any dir-prefix, then the name could be decided later and they would still be useable with standard methods of setting only the -path.
I didn't use a directory prefix, but instead a hardcoded prefix for [list]-abs mostly because many of them are impossible to use without the prefix anyways since they nameclash with existing objects like [list-moses] vs. [moses]. So "import list" doesn't make any sense for them. But for the dsp-collection I think, a directory prefix would make sense.
- using messages like 'frequency 123' to set parameters, which are
routed inside the abstraction. with such a design, only one inlet
for an arbitrary number of parameters is needed.Yes, that could be a kind of "good practice" recommendation. I do this in my personal abstractions a lot, where I now use the attached "dispatcher" to automate the creation of the necessary [route frequency] and [s $0-frequency] chains plus a tiny help-feature. (Requires pd-0.40 and up because of $1-$2)
I really like the idea of a standard library of DSP objects. I think
that one thing that can really make this project that much better is
having a clearly defined, usable, and clean common interface for this
library. I think it would be nice to use some inlets, rather than
just one inlet and a bunch of special messages.
So there could be defined classes of objects (synths, filters,
effects, etc.), and each would have a standard interface. So all
synths would have frequency and amplitude inlets, for example.
Another key part of this is using standard values for each thing.
For example, with filters, they can be specified using Q and f point,
or f and filter order (1st order/6dB, 2nd order/12dB, etc.), or other
techniques. Ideally, there would be a standard filter interface for
this standard lib.
Then for non-standard things, I think makes sense to use the messages
to the first inlet. Or perhaps the first three inlets would always
be the same thing, then the others would be available for special
parameters.
Also, standard units are important. For example, I think that the
pitch/frequency inlet should accept values in Hz and the amplitude
should always be between 0-1 like the rest of Pd. There was some
discussion about this last year:
http://lists.puredata.info/pipermail/pd-list/2006-03/036800.html
just my two bits...
.hc
- the helpfile should at least describe the available parameters and
their default values.
Yes++.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__ <dispatcher-help.pd> <dispatcher.pd> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
I really like the idea of a standard library of DSP objects. I think
that one thing that can really make this project that much better is
having a clearly defined, usable, and clean common interface for this
library. I think it would be nice to use some inlets, rather than
just one inlet and a bunch of special messages.So there could be defined classes of objects (synths, filters,
effects, etc.), and each would have a standard interface. So all
synths would have frequency and amplitude inlets, for example.Another key part of this is using standard values for each thing.
For example, with filters, they can be specified using Q and f point,
or f and filter order (1st order/6dB, 2nd order/12dB, etc.), or other
techniques. Ideally, there would be a standard filter interface for
this standard lib.
All this is so orthogonal to my original goals (described in my first mail in this thread [1]) that I'd not be able to contribute anymore.
[1] http://lists.puredata.info/pipermail/pd-list/2007-06/051109.html
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
to make a start, i put these two abstractions together (with according helpfiles):
[tr808-bd~] [tr808-cp~]
(which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 )
you can get them here:
http://www.romanhaefeli.net/software/pd/dsplib.tar.gz
i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs.
roman
On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote:
Hallo, Patco hat gesagt: // Patco wrote:
Hello,
Frank Barknecht a écrit :
All that would be necessary are a clean and documented interfaces for the DSP abstractions.
Yes exactly.
Things like state saving, GUIs or network control then could easily be built as wrapper abstractions.
It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction,
IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments.
and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction.
A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch.
That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...)
And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions.
Ciao
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
i thought, the bandlimited oscillators would fit as well into dsplib :
[blsaw~] [blsquare~] [bltriangle~]
still on: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz
roman
On Fri, 2007-06-15 at 22:20 +0200, Roman Haefeli wrote:
to make a start, i put these two abstractions together (with according helpfiles):
[tr808-bd~] [tr808-cp~]
(which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 )
you can get them here:
http://www.romanhaefeli.net/software/pd/dsplib.tar.gz
i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On 15/06/2007, at 22.20, Roman Haefeli wrote:
i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs.
If they are to be in _the_ cvs, it might be good to:
- make a project out of it, with a written up goal, ala what you
wrote in the previous email.
- make a folder in _the_ cvs named something shortish, say "inst",
where everyone can add instruments aka dsp abstraction as long as
they are true to the form specified in the "goal". The goal could be
in a simple README. Of cause only folks having write access can add
stuff.
Another form could make another project, if needed be. I see no
reason to restrict that. This would also follow the trent of the
Montreal abstraction-set.
This also brings to mind the fairly reason discussion about
instrument making. It was about defining much the same set of design
forms, but had a focus on modeling typical orchestra instruments. See
fx:
http://lists.puredata.info/pipermail/pd-list/2007-04/049367.html
beautiful piece roman, so lush.
thanks for the dsp objects too.
Yeah Roman, your track is really nice--good for a late night/early morning chill out before bedtime.
~Kyle
On 6/15/07, hard off hard.off@gmail.com wrote:
beautiful piece roman, so lush.
thanks for the dsp objects too.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
sorry for double posting again:
i thought, the bandlimited oscillators would fit as well into dsplib :
[blsaw~] [blsquare~] [bltriangle~]
still on: http://www.romanhaefeli.net/software/pd/dsplib.tar.gz
roman
On Fri, 2007-06-15 at 22:20 +0200, Roman Haefeli wrote:
to make a start, i put these two abstractions together (with according helpfiles):
[tr808-bd~] [tr808-cp~]
(which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 )
you can get them here:
http://www.romanhaefeli.net/software/pd/dsplib.tar.gz
i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Man, that sucks about the backup wackiness. Good thing your netpd efforts have multiple data sources for retention!
~Kyle
On 6/15/07, Roman Haefeli reduzierer@yahoo.de wrote:
(which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 )
you can get them here:
http://www.romanhaefeli.net/software/pd/dsplib.tar.gz
i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs.
roman
On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote:
Hallo, Patco hat gesagt: // Patco wrote:
Hello,
Frank Barknecht a Ã(c)crit :
All that would be necessary are a clean and documented interfaces for the DSP abstractions.
Yes exactly.
Things like state saving, GUIs or network control then could easily be built as wrapper abstractions.
It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction,
IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments.
and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction.
A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch.
That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...)
And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions.
Ciao
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Sat, 2007-06-16 at 12:22 -0500, Kyle Klipowicz wrote:
Man, that sucks about the backup wackiness. Good thing your netpd efforts have multiple data sources for retention!
yeah, otherwise i would have lost all instruments. the clap and kick remained, because i've already turned them into netpd-patches... thank netpd ;-)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
sorry for double posting, but it seems, that it is not only me who didn't receive that mail:
to make a start, i put these two abstractions together (with according helpfiles):
[tr808-bd~] [tr808-cp~]
(which are part of my try to rebuild all 808-instruments in plain pd, but unfortunately i lost most of the instrumenst during a harddisk backup, which made me so depressed, that i made this song: http://195.176.254.167/~all/mp3/2006-08-15_backup_blues.mp3 )
you can get them here:
http://www.romanhaefeli.net/software/pd/dsplib.tar.gz
i still don't know, what is the best way to get them into cvs. will someone collect all the works and include them? i do actually not have writing access to cvs.
roman
On Fri, 2007-06-15 at 18:40 +0200, Frank Barknecht wrote:
Hallo, Patco hat gesagt: // Patco wrote:
Hello,
Frank Barknecht a écrit :
All that would be necessary are a clean and documented interfaces for the DSP abstractions.
Yes exactly.
Things like state saving, GUIs or network control then could easily be built as wrapper abstractions.
It might be necessary to have a bridge between the wrapper and the DSP abs. This bridge would find all GUIs inside DSP abstraction,
IMO there should be no GUI at all inside the actual DSP abstraction, just a couple of documented(!) inlets and arguments.
and construct a wrapper with all necessary GUIs concatenated into one dynamically made abstraction.
A bridge with automated service discovery could be nice, but I fear that it may also be too much bureaucracy and in the end may not help, but hinder moving forward and actually getting things done. The first step should be to 1) abstract DSP out into abstraction and 2) at the same time document each of them with a stupid black and white, help-patch.
That help-patch may be quick and dirty, but it must *exist*. Keeping formalisms and requirements on help-patches etc. low, in the end will lead to them actually being written, instead of just being planned. For example every single [list]-abs has a help patch. They aren't pretty or anything, they don't all have the same layout, but they are there, which to me, now is the most important thing. (It took me a while to realize this. For example many RRADical abstractions are not documented ...)
And a service discovery bridge may also be built later as a decorator abstraction itself around the original abstractions.
Ciao
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Chris McCormick -
Enrique Erne -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
hard off -
Kyle Klipowicz -
moritz -
Patco -
Roman Haefeli -
Steffen