hey, just finished my templates. I did not concentrate so much on content and layout, but on the question how to make different patch layouts with stylesheets. I think it is a good idea to make styles as flexible as possible. https://www.puredata.info/dev/pddp/pddp-drafts So what you see is one patch where you can switch between different styles. The style definitions are in a seperate textfile and control primarily canvases and text (but you can add your own style definitions for guis...). You can set colors, fonts sizes, positions. please play around and create your own layouts! The layouts are rewritten everytime you open the patch, so you don't have to worry to overwrite when you save a patch. Besides the changes on gui objects, it is also possible to switch headers and footers (or create additional patches). They are GOPs and are scripted during runtime (when you open the patch). they can change their appearance dependent on things like language settings, operating system. But GOPS only support gui objects and comments, I really miss support for images and pddplink. you will need iemlib, zexy, pd 0.39. I only tested them on mac, so I would like to hear feedback about other os. thnx. marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
just finished my templates. I did not concentrate so much on content and layout, but on the question how to make different patch layouts with stylesheets.
Works on Linux, too.
you will need iemlib, zexy, pd 0.39.
In my opinion, this is a complete nogo: help patches must not require any externals besides the external they explain and some related ones.
Frank Barknecht _ ______footils.org_ __goto10.org__
Frank Barknecht wrote:
you will need iemlib, zexy, pd 0.39.
In my opinion, this is a complete nogo: help patches must not require any externals besides the external they explain and some related ones.
well, it was more for convenience. I use niagara and packel, because I am not so used to the new list-abs. and I use iem_send because it is much easier to use than the workarounds for dynamic send. the only object that cannot be created by pd core objects is [operating_system]. I used that to demonstrate the possibilities of on-the-fly scripting. otoh, I think pd-extended or any packged pd distro will always include these libraries. pddp is in some way a side product of pd-extended. if we only stick with core pd, we could also stay with the core help patches... I don't see why help patches should not make use of the "full" pd resources. what exactly are your points against relying on other libraries? marius.
Agreed as well - I hate opening a help patch and having to track down and enable libraries and restart pd. Honestly, though I am uninformed about this kind of stuff, couldn't the more useful objects from zexy be included in core pd? What threshold does an object or lib have to cross before it is included in pd-vanilla? I know the iem gui objects started out as externals right? And I also know that there was a decision somewhere to include many cyclone objects starting with pd-0.40 (i think......?)
Just curious :) Kevin
On 9/16/07, hard off hard.off@gmail.com wrote:
i agree with frank.
no way should help patches rely on externals.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, marius schebella hat gesagt: // marius schebella wrote:
otoh, I think pd-extended or any packged pd distro will always include these libraries. pddp is in some way a side product of pd-extended.
But even then, shouldn't you use proper namespaces and [import]? ;) But even then, I don't think, pddp should be restricted to only work with pd-extended.
I don't see why help patches should not make use of the "full" pd resources. what exactly are your points against relying on other libraries?
I'm only against this for help-patches or templates for help-patches, as this is the central ressource to get info on how to use an object. Relying on externals "just for good looks" i.e. without any technical need breaks easy accessibility of documentation.
Frank Barknecht _ ______footils.org_ __goto10.org__
hey, you give me the feeling that I am the bad guy with the bulldozer, trying to ruin all your efforts to keep pd pure and original. I think it is a fact that objects that do exist in an external library will not be included into the core pd, even if they are super cool and bugfree objects. pd behaves different than a big company that tries to swallow the neighborhood and integrate it into the core company. pd is a collaboration project. I see no reason to distinguish between core and rest. as long as the libraries are available and run on all systems. and pd-extended helps really made life a lot easier. the problem of pd help with externals is not if it looks better, but if it saves hundreds of hours of work! when I am able to set a language in my pd help, then I don't have to replace 2000 times the words inlets with "eingang" but I can do that from a central document. and just translate the rest of the patch (which is still enough work). And if such a feature would rely on an external object (like iem_send), then I definitely think we should use it.
sorry, I don't know how and if the namespace works since I only read what is NOT working, and that there are NO standards, and nobody is willing to agree on rules. I really hope, there will be an entry about [import] in the pdpedia.
marius.
Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
otoh, I think pd-extended or any packged pd distro will always include these libraries. pddp is in some way a side product of pd-extended.
But even then, shouldn't you use proper namespaces and [import]? ;) But even then, I don't think, pddp should be restricted to only work with pd-extended.
I don't see why help patches should not make use of the "full" pd resources. what exactly are your points against relying on other libraries?
I'm only against this for help-patches or templates for help-patches, as this is the central ressource to get info on how to use an object. Relying on externals "just for good looks" i.e. without any technical need breaks easy accessibility of documentation.
Ciao
Hallo, marius schebella hat gesagt: // marius schebella wrote:
you give me the feeling that I am the bad guy with the bulldozer, trying to ruin all your efforts to keep pd pure and original.
I didn't intend to do that, sorry. Ah, email ... I'm not taking part in pddp, I just wanted to express my view on that issue.
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sep 16, 2007, at 6:10 PM, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
otoh, I think pd-extended or any packged pd distro will always
include these libraries. pddp is in some way a side product of pd-extended.But even then, shouldn't you use proper namespaces and [import]? ;) But even then, I don't think, pddp should be restricted to only work with pd-extended.
Sounds like a good idea. I think that namespace prefixes are
probably the preferred option for the help patches because they
always give you the object you want, regardless of what is loaded and
how. Plus they work on pd-vanilla and pd-extended.
I don't see why help patches should not make use of the "full" pd
resources. what exactly are your points against relying on other libraries?I'm only against this for help-patches or templates for help-patches, as this is the central ressource to get info on how to use an object. Relying on externals "just for good looks" i.e. without any technical need breaks easy accessibility of documentation.
PDDP has been around for 5 years and miller has not included anything
from it. Therefore, PDDP is not part of pd-vanilla. In order to
make good help patches, we are going to have to use objects that are
not included in pd-vanilla. Pd-extended is a common platform for
using externals, and Pd-extended fully embraces PDDP. So I don't
think it's a problem to use some externals when they are useful. For
example, [pddp/pddplink] is a standard object for PDDP help patches.
That said, people should try to use common solutions, and more often
than not, those involve using pd-vanilla constructs.
As for the stylesheets, I think the idea is quite cool, but that
seems to me to be a "version 2" feature. I also played with a web-
style nav for help patches, but it turned out to be too complicated:
http://puredata.org/dev/pddp/pddp-drafts/template-10-grab.png
.hc
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
On Sun, 2007-09-16 at 12:08 +0200, Frank Barknecht wrote:
Hallo, marius schebella hat gesagt: // marius schebella wrote:
just finished my templates. I did not concentrate so much on content and layout, but on the question how to make different patch layouts with stylesheets.
Works on Linux, too.
you will need iemlib, zexy, pd 0.39.
In my opinion, this is a complete nogo: help patches must not require any externals besides the external they explain and some related ones.
first: i agree with frank. having to have additional externals installed destroys the whole idea of accessing information by the most simple way. for me it is very clear, that making help patches dependent on third party externals (others than the help patches describe) is certainly not the way to go.
second: i am pretty sure, that the only object of zexy, that cannot be replaced by internals, is [symbol2list] (which i really would like to have included in pd, but thats a different story). if you are not using this object, then go on while skipping zexy. tell me if you need help. i would also be interested, which objects from iemlib you use.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Sun, 2007-09-16 at 19:38 +0200, Roman Haefeli wrote:
second: i am pretty sure, that the only object of zexy, that cannot be replaced by internals, is [symbol2list] (which i really would like to have included in pd, but thats a different story).
yo, sorry, this isn't true. what i meant is that almost all message objectclasses can be replaced by internals (not the tilde objectclasses), but there are still some, which cannot, like:
[symbol2list] [operating_system] [repeat] (when working with pointers)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
tell me if you need help. i would also be interested, which objects from iemlib you use. roman
I already said, I use niagara and packel, which probably can be replaced by list-abs objects. and iem_send (a settable send object). I need to send lists of variable length to a receiver that is created by $0- and the first element of the received list ($0-pddp.cnv.header). I know that 0.40 has the settable send, but 0.39 does not. and I also know how to do the work around, but I assume it is slower and ugly. marius.
Hallo, marius schebella hat gesagt: // marius schebella wrote:
I already said, I use niagara and packel, which probably can be replaced by list-abs objects.
No need for list-abs, they are practically included in Pd. Attached patch is your homework assignement for Tuesday. ;)
Frank Barknecht _ ______footils.org_ __goto10.org__
the "new" send (which takes a set message) is only included with pd 0.40 and up. marius.
IOhannes m zmoelnig wrote:
marius schebella wrote:
and iem_send (a settable send object).
but why don't you just use [send]?
fmga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
marius schebella wrote:
the "new" send (which takes a set message) is only included with pd 0.40 and up.
hopefully no send implementation will ever have a "set" message that changes its behaviour....
otoh, pd-0.40 has been available for more than a year now, so why not use it?
instead of using hacks depending on externals, it would be better to invest the energy in helping hans to get pd-extended-0.40 released,
mfg.ft IOhannes
sorry that I was not precise. the "new" send object has a right inlet that takes a message [symbol x( to set the new destination. It is the same as iem_lib. So since the whole "style" feature is in an abstraction, I can easily change that in one central file. at the moment it relies either on iem_send, or pd 0.40up. but I will change it anyway so that it does not rely on either one... marius.
IOhannes m zmoelnig wrote:
marius schebella wrote:
the "new" send (which takes a set message) is only included with pd 0.40 and up.
hopefully no send implementation will ever have a "set" message that changes its behaviour....
otoh, pd-0.40 has been available for more than a year now, so why not use it?
instead of using hacks depending on externals, it would be better to invest the energy in helping hans to get pd-extended-0.40 released,
mfg.ft IOhannes
the niagara / packel stuff you can easily substitute with [list split 1]
and then you're rocking pddp vanilla style!
not bad!! The only solution I knew of was to use a message, clear it and then add one element after the other, and then bang it to send it. but this solution had a problem, every time you send a message to an object that does not exist, you get an error message. so I really appreciate your solution! marius.
hard off wrote:
i got it!
a settable send using only pd vanilla objects.
see the attached patches.
iohannes,
you're right. super simple now. thanks mate.
simplified patch is attached.
ok, finally after testing with my pddp draft, it does not work. I think it is because it is not fast enough. when I use it in combination with textfile and a loop, then I get a lot of error messages, nothing is scripted to the subpatch, or maybe only the first message (clear) but the rest not? too bad. marius.
IOhannes m zmoelnig wrote:
marius schebella wrote:
that's not working anymore, because the send does not have $0- marius.
?? [sentsend] has no $0- either.
at least: the new patch is working fine here.
mfga.sdr IOhannes
Hey,
Post those receive symbols that you wanted so that I can include them.
.hc
On Sep 18, 2007, at 2:07 PM, marius schebella wrote:
ok, finally after testing with my pddp draft, it does not work. I think it is because it is not fast enough. when I use it in combination with textfile and a loop, then I get a
lot of error messages, nothing is scripted to the subpatch, or maybe only the first message (clear) but the rest not? too bad. marius.IOhannes m zmoelnig wrote:
marius schebella wrote:
that's not working anymore, because the send does not have $0- marius.
?? [sentsend] has no $0- either.
at least: the new patch is working fine here.
mfga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
hello hans, I am relying to your template12:
header-canvas: $0-pddp.cnv.header
horizontal sections: $0-pddp.cnv.section1
vertical sections: $0-pddp.cnv.section2
footer: $0-pddp.cnv.footer
marius.
Hans-Christoph Steiner wrote:
Hey,
Post those receive symbols that you wanted so that I can include them.
.hc
On Sep 18, 2007, at 2:07 PM, marius schebella wrote:
ok, finally after testing with my pddp draft, it does not work. I think it is because it is not fast enough. when I use it in combination with textfile and a loop, then I get a lot of error messages, nothing is scripted to the subpatch, or maybe only the first message (clear) but the rest not? too bad. marius.
IOhannes m zmoelnig wrote:
marius schebella wrote:
that's not working anymore, because the send does not have $0- marius.
?? [sentsend] has no $0- either.
at least: the new patch is working fine here.
mfga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Mistrust authority - promote decentralization. - the hacker ethic
On Mon, 2007-09-17 at 16:59 +0200, IOhannes m zmoelnig wrote:
hard off wrote:
i got it!
a settable send using only pd vanilla objects.
why don't you just use [send] instead of [setsend]? i don't see any added functionality in this abstraction (but an added dependency on the abstraction)
are you reading the list?
it's about to overcome the problem, that the settable [send] is an only
=0.40 feature.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
On Mon, 2007-09-17 at 16:59 +0200, IOhannes m zmoelnig wrote:
hard off wrote:
i got it!
a settable send using only pd vanilla objects.
why don't you just use [send] instead of [setsend]? i don't see any added functionality in this abstraction (but an added dependency on the abstraction)
are you reading the list?
yes i am.
it's about to overcome the problem, that the settable [send] is an only
=0.40 feature.
i am not talking about using the new (set) feature of [send], but about replacing [setsend] with [send].
have you had a look at [setsend]?
[inlet] | [send $1]
which is a wrapper for [send]: it has the very same functionality (in any version of pd)
fmadsr. IOhannes
That will be handy for PDa patches, since there is no [prepend],
[list] or settable [send] in PDa.
.hc
On Sep 17, 2007, at 10:35 AM, hard off wrote:
i got it!
a settable send using only pd vanilla objects.
see the attached patches. <newsend.zip> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television
FYI: with the PDDP templates, we are aiming for 0.40 and up since Pd- extended 0.39.3 is basically released.
.hc
On Sep 17, 2007, at 8:34 AM, marius schebella wrote:
the "new" send (which takes a set message) is only included with pd
0.40 and up. marius.IOhannes m zmoelnig wrote:
marius schebella wrote:
and iem_send (a settable send object).
but why don't you just use [send]?
fmga.sdr IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
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
Hi Marius,
Thanks for taking the dive and contributing ideas to the wiki. I'll "strike" that task from your todo list. How is the wiki template going?
I think the discussion about externals was well played out, what have you ended up deciding? (Will your stylesheet system work on vanilla PD 40?)
I am a little confused about the purpose of these templates though, as I thought you had issues with the way the information was structured in previous templates (and the over use of canvases) and now I see you have even more canvases (cnv)!
Here is some feedback:
works for multi-lingual PD. Of course the comments would still be unilingual without lots of extra effort.
content does not really flow well, as they are different sizes. The extra space for the patch area is nice, but I think most examples need more vertical space than horizontal, even with template 11 the example patch is still floating in a lot of empty space. See template 6 for an example of another alt design that had a bigger patch area.
the content, so that are all the width of the text area or so, when they are too short they no longer serve to break up the content because they need to have more emphasis on the text.
Would you consider making template 11 stylesheet compatible?
See my other message about GOPing pddplink.
Great to see all this effort! :)
.b.
marius schebella wrote:
hey, just finished my templates. I did not concentrate so much on content and layout, but on the question how to make different patch layouts with stylesheets. I think it is a good idea to make styles as flexible as possible. https://www.puredata.info/dev/pddp/pddp-drafts So what you see is one patch where you can switch between different styles. The style definitions are in a seperate textfile and control primarily canvases and text (but you can add your own style definitions for guis...). You can set colors, fonts sizes, positions. please play around and create your own layouts! The layouts are rewritten everytime you open the patch, so you don't have to worry to overwrite when you save a patch. Besides the changes on gui objects, it is also possible to switch headers and footers (or create additional patches). They are GOPs and are scripted during runtime (when you open the patch). they can change their appearance dependent on things like language settings, operating system. But GOPS only support gui objects and comments, I really miss support for images and pddplink. you will need iemlib, zexy, pd 0.39. I only tested them on mac, so I would like to hear feedback about other os. thnx. marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I'll also throw in my attempt to the ring. Or "pre-ring" perhaps I
should say. ;) I like the overall layout of Ben's template 9, but I
think that the graphical elements are too heavy, drawing too much
attention.
I took Ben's original template-9 and applied some concepts I've been
thinking, reading, etc. about. Bradford Paley has a lot of really
good things to say about interface design, outlined in this talk:
http://atlas-real.atlas.uiuc.edu:8080/refmov/ncsa/2005-11-04-0800pm.asx
(FYI: you can rip the stream with VLC, then watch it at 1.25X speed,
since he speaks with a lot of pauses).
Therefore, I made the 'structural' elements in the background as much
as possible to make the examples and text come forward. The color on
the header is to mark the patch as a help/reference patch, versus a
tutorial or all_about patch.
http://eds.org/~hans/template-HCS.png
.hc
On Sep 17, 2007, at 5:02 PM, B. Bogart wrote:
Hi Marius,
Thanks for taking the dive and contributing ideas to the wiki. I'll "strike" that task from your todo list. How is the wiki template
going?I think the discussion about externals was well played out, what have you ended up deciding? (Will your stylesheet system work on vanilla
PD 40?)I am a little confused about the purpose of these templates though,
as I thought you had issues with the way the information was structured in previous templates (and the over use of canvases) and now I see you
have even more canvases (cnv)!Here is some feedback:
- I think the idea of the stylesheet is a good one, especially as it
works for multi-lingual PD. Of course the comments would still be unilingual without lots of extra effort.
- Where did the three panel layout come from? Having two columns
for the content does not really flow well, as they are different sizes. The extra space for the patch area is nice, but I think most examples need more vertical space than horizontal, even with template 11 the example patch is still floating in a lot of empty space. See template 6 for an example of another alt design that had a bigger patch area.
- The purpose of the canvases in the previous templates is to break up
the content, so that are all the width of the text area or so, when
they are too short they no longer serve to break up the content because
they need to have more emphasis on the text.
- All in all I don't see any improvement of this design to template
11, Would you consider making template 11 stylesheet compatible?
See my other message about GOPing pddplink.
Great to see all this effort! :)
.b.
marius schebella wrote:
hey, just finished my templates. I did not concentrate so much on
content and layout, but on the question how to make different patch layouts with stylesheets. I think it is a good idea to make styles as flexible as possible. https://www.puredata.info/dev/pddp/pddp-drafts So what you see is one patch where you can switch between different styles. The style definitions are in a seperate textfile and control primarily canvases and text (but you can add your own style
definitions for guis...). You can set colors, fonts sizes, positions. please play around and create your own layouts! The layouts are rewritten everytime you open the patch, so you don't have to worry to overwrite when you save a patch. Besides the changes on gui objects, it is also possible to switch headers and footers (or create additional patches). They are GOPs and are scripted during runtime (when you open the patch). they can
change their appearance dependent on things like language settings,
operating system. But GOPS only support gui objects and comments, I really miss support for images and pddplink. you will need iemlib, zexy, pd 0.39. I only tested them on mac, so I would like to hear feedback about
other os. thnx. marius.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On 18/09/2007, at 6.41, Hans-Christoph Steiner wrote:
Nice work Hans. I really like the graphical cut down. I surgest to
cut away the symbols to explain what inlet (outlet) are in question
for the horizontal part. Reason: it's not really needed, hence
contrary to the design ideas you have been applying. And it (cutting
them) will serve more space on the right side for text/info. And
last, it might just work for 'float' but might well not work for
other more cluttered object-classes.
I'm talking about those:
| [float]
|
[float]
[float] |