idea of "new" netpd
actually setting up netpd means:
- adding the path to the netpd-abs to pd's startup options
- adding the needed libs to pd's startup options
- setting the correct path to the netpd-folder in netpd-settings
these three steps make the installing of netpd a bit more difficult than desired and are the reason, why one cannot say, that netpd runs out-of-the-box. i had many talks with different people about how to make installing of netpd easier, but for a long time no solution was found. while netpd has evolved , pd was better developed as well and thus introduced some changes, which makes it in the end possible to turn netpd into an out-of-the-box application.
with pd 0.40 a new object [declare] was introduced, which allows to add pathes to pd's search pathes on the fly. it also can be used to load the necessary libs, so that no more startup options are needed, when running pd, respectively netpd. regarding pathes, pathes added by [declare -path] are only valid withing the patch, that contains the [declare]. therefore actual netpd cannot profit from [declare]'s features.
to overcome this limitation of [declare], the idea came up to turn whole netpd into one single patch. this means, that creator is an abstraction within chat, all netpd-patches are abstractions withing creator etc. this structure has two very important goals:
- a [declare -path] loads the given path for all subsequent patches aka. abstractions.
- the netpd-path setting becomes obsolete, because abstractions are searched relative to the parent patch and not relative to pd's start location (as it is the case with the open message to pd).
as it can be seen, such a design would make netpd get rid of all the above steps to set up netpd.
todo-list
- all netpd-programs get part of chat (as abstractions)
- chat: add [declare] with all libs and pathes into chat.
- chat: change all remaining
chat-somethingtonetpd-something - creator: dynamic subpatches to load netpd-patches as abstractions into
- creator: new gui with scrollbar
- creator: loadlist in order to load known patches faster
- (...)
added by roman
eerne hi roman. what is the status about the new netpd ? i had some ideas about the gui and would be willing to contribute. read on...
thoughts about netpd gui
- netpd-skins
- increase hack- and accessibility by abstracting netpd's chat interface
with a relatively small change by moving the interface of the chat gui to an abstraction, the netpd interface would gain easy access for personal modifications. users could customize their own skins. even other techniques, like gem and datatructes, could be used. maybe some new ideas would find the way back into the standard gui.
it would be necessary to adjust the receive and send msgs of all GUI (bang, toggle, symbol, canvas) by either an $1 argument or a naming scheme (chat.send chat.send-r). a list in a wiki page could provide all aviable names.
the gui should popup on loadbang and the main patch possibly switched to hidden. this function could be part of the skin abstraction. it could also hold the code to display a certain number of past msgs. maybe other gui related code would be suitable to get included with the gui-abs.
an extended skin example could be a standart chat with more gui as dsp, gemwincontrol master.volume quit midi activity display asciiart any possibly many more functions.
a simplified skin could be customized for children, netpd-terminals at an exhibition or inconspicuous small windows at work.
a first test based on chat v1.4.1 with the gui moved into netpd/abs/netpd-gui.pd