traktandum 1)

netpd/tut/: all patches from netpd/tut/ are currently broken and need a [declare] in order to be able to load the netpd-abstractions

comment by roman: changed already

traktandum 2)

netpd/doc: currently they are not accessible by right-click->help, if their path is not specified with the -helppath flag in pd-settings or .pdrc. we decided to move them and all other help-patches of custom abstractions into netpd/abs, where they are found automatically.

comment by roman: changed already

traktandum 3)

dependencies: currently some standard libraries are defined and also loaded by netpd (chat). since the introduction of [declare], this is not necessary anymore and custom [barry]? and abtractions can load their dependencies themselves. all custom [barry]? need to be changed in order to comply with that new strategy. Preliminary chat loads the current standard libs.

traktandum 4)

it was mentioned, that probably 90% of all non-signal externals could be rebuilt using the lua scripting language with the pdlua external. therefore it was discussed to add native support for lua scripts in netpd, so that they could be added to [pd abslist]. while only one additional external needs to be installed, scripts could be bundled and distributed with [barry]?.

some notes about the implementation: since creator doesn't use any real mechanism to check the existence of files, but just simply tries to load them with [textfile], it's a bad idea to search for both, files with .pd and with .lua extension, because this would cause an error, whenever a file is not found. this means, that it would be necessary to specify the lua scripts with extension in the abslist, e.g ![myscript.lua(

thanks to syntax for bringing up this idea.

traktandum 5)

switch to OSC (longterm plan)

currently for the transport netpd is based on [netclient] and [netserver] for establishing a tcp connection. the protocol used by netpd is based on FUDI, proprietary and not compliant with any other existing protocol (besides FUDI, of course). it was discussed, if netpd could benefit from a switch to OpenSoundControl. there are some evident advantages:

1. there are some limitations by using FUDI. OSC is much more flexible.
2. there is no sense in implementing what is already there. already existing concepts can be used.
3. OSC works (similar to the current protocol) with '<key> <value>' messages. for <key> or parts of <key> wildcards can be used.
4. there are a lof of softwares already using OSC. going the OSC route would make netpd interoperable with those much more easily.
5. the netpd-abstractions could be switched to OSC transparently, so that the custom netpd-patch using those abstractions wouldn't need any change at all.
6. netpd could get rid of the dependency on the maxlib library, which isn't officially mainained anymore. instead, externals by mrpeach could be used, which are still maintained (and probably will be for the next few years) and are known to work well.

However, there are also some issues:

1. another depencency is introduced
2. [barry]?, which use their own code on the communication level need to be adapted.

this is certainly an idea, that still needs to get mature. any hints, ideas, discussions are welcome.

Question:

[r netpd-receive]

|

[route master.switch]

would that have to be changed and how?

commen by roman: i am not sure, if i understand the question. AFAIK, master uses netpd-abstractions, so there is no need to change it and it should work after the change as well without any change to master itself.

organizing public servers

the fact needs to be faced, that also other people and/or groups run their own public netpd-servers. at first glance there is no problem with it and of course, everyone is free to use and run all the patches from the netpd-project, including the server-patch. however, the protocol and the even the server-patch is might be subject to be changed. as long as only one server on netpd.org is running, there is no problem at all, since it easily can be updated by the netpd maintainers. but if several servers spread over the world are running, keeping the netpd world consistent might become a problem. a way to inform other netpd service providers (haha, what a funny sounding term, sounds quite economic. would be cool if people could make some money one day by running a netpd-server, though ;-) ) is required in order to give them the chance to update their servers. also the protocol used by netpd needs to have a version number, as long as it is subject to be changed. further should clients check, whether they understand the protocol version provided by the server. finally also a way to make all existing server easily accessible needs to implemented, so that clients could check, which servers are around, which are currently online etc.

yo, i am just throwing some ideas here.. comments welcome!

more than one channel per server

the idea was brought up today (i think not for the first time). i wonder, how much is it wanted. how should it work? should there be a fixed number of rooms? should any client be able to create its own room?