(assuming that this message didn't arrive to the list, sorry if you've received this mail twice, I've also corrected the end of the message)
Hi eni,
Le samedi 09 juin 2007 à 11:26 +0200, Enrique Erne a écrit :
hi patko
if you miss an abstraction there is something wrong with your setup.
No, I seriously think that if I miss an abstraction, there is something wrong with the documentation, or comments, and I am not talking about net-pd. I'd rather rebuild my own set of abstractions than looking for the missing patch if I have to surf internet, ask questions to pd-list for getting answers. An undocumented patch is almost always a waste of time for every pd users. I can tell this for myself too.
i think i can say _every_ netpd-patch that uses abstractions has a subpatch [pd abslist] with a list of msgs containing all used abstractions.
when one netloads a patch, _creator.pd will read the abslist and
tells
all the users that it is going to upload a patch with the specific abstractions and version number.
Yes, that's a very cool functionning, it could save everyone a lot of time, and it would be even better if _creator.pd was able to update itself, and why not letting it update absolutely all the files (even the ones in the bin directory)? It would certainly require a 'pd repositories'.
i was thinking about removing my name from the patches and make it
more
welcome for changes (see kyle's movie about os)... so far we were cautious in changing others patches. usually we change the name ultrahardcoresynth-eni.pd and do changes
and
suggest it to the original author... but many authors are not active.. hmm
that's
an other topic.
Instead of uploading abstraction from a net-pd user's computer, it might be better if the abstraction were uploaded from a net-pd repository. Any one that would like to add abstractions to net-pd would have to submit them to an active authority of the net-pd project, then it would avoid a lot of mistakes, and the autor would still be referenced but rather in a net-pd database than into the patch, were more usefull information could be displayed.
what information would you like to see in the patches ?
I simply would like to be able to understand without having to browse all patches and subpatches hundreds of times for having a clue about how the objects are functionning. For example if I want to put an FX-insert into an net-pd instrument I've made, I take a look at how it has been implemented in other intruments and in the mixer, and I give up after two hours because it's a real mess, there is absolutely no explanations anywhere. Just seeing 'information' would be a good start, ;).
- dependencies...
Well I hope you've seen that we are talking about two different things through this discussion, net-pd and pd-extended, and net-pd allready resolve this 'dependence' problem with [pd abslist]. Maybe [import] in pd-extended would fix missing externals, with at least giving the name of the missing ones.
what do you mean with "original abstractions" ?
Let's say: "an abstraction that isn't into the pd documentation"
good morning patrice
On Jun 9, 2007, at 4:48 PM, patrice colet wrote:
(assuming that this message didn't arrive to the list, sorry if you've received this mail twice, I've also corrected the end of the message)
Hi eni,
Le samedi 09 juin 2007 à 11:26 +0200, Enrique Erne a écrit :
hi patko
if you miss an abstraction there is something wrong with your setup.
No, I seriously think that if I miss an abstraction, there is something wrong with the documentation, or comments, and I am not talking about net-pd. I'd rather rebuild my own set of abstractions than looking for the missing patch if I have to surf internet, ask questions to pd-list for getting answers.
i thought you got the patch through netpd's creator.
please tell me which patch is missing an abstraction and where you got it from, sp i can fix it. at least it should be mentioned in the wiki.
An undocumented patch is almost always a waste of time for every pd users. I can tell this for myself too.
i'm afraid all my patches have no comments, sorry. i tried to put the most important information to the netpd-wiki
i think i can say _every_ netpd-patch that uses abstractions has a subpatch [pd abslist] with a list of msgs containing all used abstractions.
when one netloads a patch, _creator.pd will read the abslist and
tells
all the users that it is going to upload a patch with the specific abstractions and version number.
Yes, that's a very cool functionning, it could save everyone a lot of time, and it would be even better if _creator.pd was able to update itself
i don't know if creator can update itself, but that sounds like micrsoft/apple "new software has been installed, your computer is ready to restart" :-)
, and why not letting it update absolutely all the files (even the ones in the bin directory)? It would certainly require a 'pd repositories'.
netclient/netserver sends ascii data which we use for patches and control information.
Instead of uploading abstraction from a net-pd user's computer, it might be better if the abstraction were uploaded from a net-pd repository. Any one that would like to add abstractions to net-pd would have to submit them to an active authority of the net-pd project, then it would avoid a lot of mistakes, and the autor would still be referenced but rather in a net-pd database than into the patch, were more usefull information could be displayed.
i personally don't like the idea of an authority deciding which patches get accepted for the netpd project.
i prefer the free direct system it now has. if you fix a bug just increase the version msg and netload it again. every user connected get's the fix.
all the user have the same rights. no royalty. no "animalfarm" also the server is only the gate to others.. it doesn't do much else than sending the incoming msgs to the connected users.
a while back we had a user running 24/7. that one would get automatically all patches ever netloaded. i'd love to have this user online again and maybe even with its netpd directory in public_html so everybody could get these files.
what information would you like to see in the patches ?
I simply would like to be able to understand without having to browse all patches and subpatches hundreds of times for having a clue about how the objects are functionning. For example if I want to put an FX-insert into an net-pd instrument I've made, I take a look at how it has been implemented in other intruments and in the mixer, and I give up after two hours because it's a real mess, there is absolutely no explanations anywhere.
it's not quite true that there is absolutely no explanation. see links http://www.netpd.org/mx http://www.netpd.org/I2mx http://www.netpd.org/HowtoBuildFx4Mx
Just seeing 'information' would be a good start, ;).
yes sure! i'm sorry that i didn't comment my patches... but in example of the netpd-mixer you should be able to use it without having a look at mx.pd
all you need to make a instrument fully use the mx (as described in netpd.org/I2mx) is an abstraction [i2mx~ $0 yourinstrumentname]
i don't think that it is a good idea to put these instructions into the abstractions.
also you are very welcome to login the netpd chat and ask before you spend other 2 hours.
regards
eni
Good afternoon, Eni, :)
Le dimanche 10 juin 2007 à 12:24 +0200, Enrique Erne a écrit :
good morning patrice
i thought you got the patch through netpd's creator.
I'm sorry, I've mixed two different discussions, this part wasn't net-pd related.
please tell me which patch is missing an abstraction and where you got it from, sp i can fix it. at least it should be mentioned in the wiki.
Concerning net-pd, I'd rather have suggestions that certainly won't be taken into account, because I've ever given a try in net-pd chat, it's about aesthetic of some patches, for example, one you've developped called 'jamx'; this sequencer is very usefull, ... but it misses very handfull things for composing faster, like copy-paste between each page, colored buttons. Let alone the missing polyphonic stuff, I know how it could be difficult to make one with pd-vanilla gui, and that you have ever done a good very job.
i don't know if creator can update itself, but that sounds like micrsoft/apple "new software has been installed, your computer is ready to restart" :-)
My mind might be corrupted by long years of composing on such environment, :D
netclient/netserver sends ascii data which we use for patches and control information.
Oh yes, and haven't you developped a patch that dynamically build patches from pd files, it's very interesting, I think it could be used for implementing on net-pd environment any pd-vanilla patch with replacing adc~ dac~ for connecting it to the mixer, sorry, my head is full of those kinds of crappy ideas...:p
i personally don't like the idea of an authority deciding which patches get accepted for the netpd project.
i prefer the free direct system it now has. if you fix a bug just increase the version msg and netload it again. every user connected get's the fix.
all the user have the same rights. no royalty. no "animalfarm" also the server is only the gate to others.. it doesn't do much else than sending the incoming msgs to the connected users.
Agreed.
see links http://www.netpd.org/mx http://www.netpd.org/I2mx http://www.netpd.org/HowtoBuildFx4Mx
Ok, thanks.
i don't think that it is a good idea to put these instructions into the abstractions.
not even an html link?
also you are very welcome to login the netpd chat and ask before you spend other 2 hours.
I'll be glad to have a jam session soon...
regards
eni
Best, Patko.
grüezi patrice
On Jun 10, 2007, at 5:41 PM, patrice colet wrote:
Le dimanche 10 juin 2007 à 12:24 +0200, Enrique Erne a écrit :
please tell me which patch is missing an abstraction and where you got it from, sp i can fix it. at least it should be mentioned in the wiki.
Concerning net-pd, I'd rather have suggestions that certainly won't be taken into account, because I've ever given a try in net-pd chat, it's about aesthetic of some patches, for example, one you've developped called 'jamx'; this sequencer is very usefull, ... but it misses very handfull things for composing faster, like copy-paste between each page, colored buttons. Let alone the missing polyphonic stuff, I know how it could be difficult to make one with pd-vanilla gui, and that you have ever done a good very job.
it would be very nice to have copy/paste .... shouldn't be to hard actually. also polyphony would be awesome... although i don' think it's a good idea to make jamx polyphonic, since all synths using it are monophonic anyway and the gui would be to overloaded (16*32 toggles ?) i'm just happy that jamx works as far as i know without bugs .. it took quite a while, the version is 0.1.26 :-)
my focus is more on mMm ... that we have a good arranger/sequencer here but no time right now. :-(
i don't know if creator can update itself, but that sounds like micrsoft/apple "new software has been installed, your computer is ready to restart" :-)
My mind might be corrupted by long years of composing on such environment, :D
netclient/netserver sends ascii data which we use for patches and control information.
Oh yes, and haven't you developped a patch that dynamically build patches from pd files, it's very interesting, I think it could be used for implementing on net-pd environment any pd-vanilla patch with replacing adc~ dac~ for connecting it to the mixer, sorry, my head is full of those kinds of crappy ideas...:p
yes that was "[PD] slowly load a pd-patches/abs without dropouts" would be interesting to see if that concept worked with dyn~ it would need a converter i believe but dyn~ has some limitations i think you can't use s~ or similar..
i personally don't like the idea of an authority deciding which patches get accepted for the netpd project.
i prefer the free direct system it now has. if you fix a bug just increase the version msg and netload it again. every user connected get's the fix.
all the user have the same rights. no royalty. no "animalfarm" also the server is only the gate to others.. it doesn't do much else than sending the incoming msgs to the connected users.
Agreed.
see links http://www.netpd.org/mx http://www.netpd.org/I2mx http://www.netpd.org/HowtoBuildFx4Mx
Ok, thanks.
i don't think that it is a good idea to put these instructions into the abstractions.
not even an html link?
you're right. i'll add the link next time.
also you are very welcome to login the netpd chat and ask before you spend other 2 hours.
I'll be glad to have a jam session soon...
maybe today with roman in vienna ?
regards
eni
Best, Patko.
On Sat, 2007-06-09 at 16:48 +0200, patrice colet wrote:
No, I seriously think that if I miss an abstraction, there is something wrong with the documentation, or comments, and I am not talking about net-pd. I'd rather rebuild my own set of abstractions than looking for the missing patch if I have to surf internet, ask questions to pd-list for getting answers. An undocumented patch is almost always a waste of time for every pd users. I can tell this for myself too.
i totally agree. and i think also that it is a good practice to inform the authors about what is missing.
i think i can say _every_ netpd-patch that uses abstractions has a subpatch [pd abslist] with a list of msgs containing all used abstractions.
when one netloads a patch, _creator.pd will read the abslist and
tells
all the users that it is going to upload a patch with the specific abstractions and version number.
Yes, that's a very cool functionning, it could save everyone a lot of time, and it would be even better if _creator.pd was able to update itself, and why not letting it update absolutely all the files (even the ones in the bin directory)? It would certainly require a 'pd repositories'.
it is very difficult to transmit binary data over the net within pd. binary executables are os/platform specific and are not portable, so i don't see any sense in distributing externals/binaries. updating netpd itself through creator might would make sense, though it must be very stable. might be implemented in the future.
i was thinking about removing my name from the patches and make it
more
welcome for changes (see kyle's movie about os)... so far we were cautious in changing others patches. usually we change the name ultrahardcoresynth-eni.pd and do changes
and
suggest it to the original author... but many authors are not active.. hmm
that's
an other topic.
Instead of uploading abstraction from a net-pd user's computer, it might be better if the abstraction were uploaded from a net-pd repository. Any one that would like to add abstractions to net-pd would have to submit them to an active authority of the net-pd project, then it would avoid a lot of mistakes, and the autor would still be referenced but rather in a net-pd database than into the patch, were more usefull information could be displayed.
the aim of netpd is to provide a framework, in which selfwritten code can be used. i think this selfwritten code should stay in the authority of the author and not be moved to some 'superior' authority. something that we all want, are patches, that just work and are portable. i believe that this could rather reached by letting the principles of darwin rule (patches that don't work out of the box or are too complicated won't be used and so not distributed), rather than one needing to play god in order to keep the world running.
what information would you like to see in the patches ?
I simply would like to be able to understand without having to browse all patches and subpatches hundreds of times for having a clue about how the objects are functionning. For example if I want to put an FX-insert into an net-pd instrument I've made, I take a look at how it has been implemented in other intruments and in the mixer, and I give up after two hours because it's a real mess, there is absolutely no explanations anywhere.
checkout the netpd wiki on http://netpd.org . since many netpd-patches are depending on others, it is far more easy to document them online, where docus can be linked. before searching any other resources, i'd try http://www.netpd.org/patchname first.
for the specific issue about creating your own fxlibs, there is much docu online (see eni's post).
what do you mean with "original abstractions" ?
Let's say: "an abstraction that isn't into the pd documentation"
are you still talking about netpd?
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 Sat, 2007-06-09 at 16:48 +0200, patrice colet wrote:
what do you mean with "original abstractions" ?
Let's say: "an abstraction that isn't into the pd documentation"
are you still talking about netpd?
roman
Well I have to review one more time the definition of "original abstractions", for something more general, to say that it's about abstractions outside of any context, and anyway, if this concept was well defined, would it still have an originality?
Roman Haefeli a écrit :
the aim of netpd is to provide a framework, in which selfwritten code can be used. i think this selfwritten code should stay in the authority of the author and not be moved to some 'superior' authority. something that we all want, are patches, that just work and are portable. i believe that this could rather reached by letting the principles of darwin rule (patches that don't work out of the box or are too complicated won't be used and so not distributed), rather than one needing to play god in order to keep the world running.
The word 'Authority' has a downside effect I didn't even expected, because it has an explicit sociological connotation linked to 'superior authority' that doesn't even make sense into the context of gnu softwares. By the way of authority, I mean coordinator(s) that has access to net-pd archives, cvs, or anything, and would communicate with patch authors about things that work, and other things that don't work. Maybe it's too much demanding, especially if there are not a lot of people that has access to the dev/distribution of the main net-pd patches. pk