Re: [PD] [tabread~~] (again)

[Roman Haefeli]

On Fri, 2007-12-07 at 08:00 +0100, IOhannes m zmoelnig wrote:
> Roman Haefeli wrote:
> > hi 
> > 
> > i wanted to play with [tabread~~] and checked out a fresh zexy and
> > compiled and it went fine. when instantiating [tabread~~], i get an
> > error though:
> 
> this is a bug in Pd's hexloader that has been fixed in the latest and 
> greatest 0.41-test release.
> altenatively you could use the hexloader to load tabread4~~.

works. thank you a lot.

> otoh, the recommended way (by upstream developers) of using zexy is 
> still as a library instead of single externals

yeah, works as well. i trapped myself, because i just switched a few
days ago from zexy.pd_linux to singleobjectclass.pd_linux. i haven't
thought about issues with filenames and i am surprised that bla~~ is a
problem and bla~ isn't. 

however, it causes me a bit head scraping to hear that the library is
the recommended format. is there a particular reason for this (i mean,
since hexloader is working)?
the reason, why i switched was to be aware of and avoid possible
problems of my patches with pd-extended beforehand. since it is probably
the quasi standard now, i would like my patches to work fine there as
well. however, when loading hexloader, these problems won't show up
anymore, which is kind of against the initial reason for going the
single-object way. 

hans: [<~],[>~] and [tabread4~~] will load in pd-extended-0.40, right?  

> so: are there any problems when you try to compile zexy as a lib?

no.

back to [tabread~~]:
is there any point in using it without a [line~~] or [vline~~]? if yes,
how is it supposed to be used? 

thanks
roman





___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] metastudio 0.2 released

[Ed Kelly]

Hi all,

Metastudio v0.2 is released. Some bugfixes (e.g. the sequencers now copies the 
current pattern properly when "new" is banged) and some improvements - the 
demoresynthfx patch contains an explaination of some machines, and a new effect 
- tabmask~ - an FFT phaser.

get it here: http://sharktracks.co.uk/puredata/metastudio-v0.2.zip
read about it here: http://sharktracks.co.uk/puredata

enjoy ;-D
Ed
 
Lone Shark "Aviation" out now on http://www.pyramidtransmissions.com
http://www.myspace.com/sharktracks




  __
Sent from Yahoo! - the World's favourite mail http://uk.mail.yahoo.com
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [tabread~~] (again)

[IOhannes m zmoelnig]

Roman Haefeli wrote:
> hi 
> 
> i wanted to play with [tabread~~] and checked out a fresh zexy and
> compiled and it went fine. when instantiating [tabread~~], i get an
> error though:

this is a bug in Pd's hexloader that has been fixed in the latest and 
greatest 0.41-test release.
altenatively you could use the hexloader to load tabread4~~.

otoh, the recommended way (by upstream developers) of using zexy is 
still as a library instead of single externals

so: are there any problems when you try to compile zexy as a lib?


fmadrs.
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd and max (2)

[IOhannes m zmoelnig]

Chris McCormick wrote:
> On Thu, Dec 06, 2007 at 07:45:41PM -0500, marius schebella wrote:
> 
> In fact, Pd has such a free license that you can even fork it and make
> your own closed-source commercial product out of it if you want. The
> only requirement is that you include the license and copyright.


and having a "free license" does not mean that it has "no licencing".
a license is not the same as a license key or a license fee.
instead it is a contract between the user and the owner of the code (or 
something like this)


fgmadsr
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] [tabread~~] (again)

[Roman Haefeli]

hi 

i wanted to play with [tabread~~] and checked out a fresh zexy and
compiled and it went fine. when instantiating [tabread~~], i get an
error though:

load_object: Symbol "setup_tabread40x7e_tild" not found
 tabread4~~
... couldn't create

grep -d recurse "setup_tabread40x7e_tild" externals/

showed me only:

externals/zexy/src/tabread4~~.c:void setup_tabread40x7e_tilde(void)
Binary file externals/zexy/src/tabread4~~.o matches
Binary file externals/zexy/src/tabread4~~.pd_linux matches


note the 'e' at the end of "void setup_tabread40x7e_tilde(void)" while
pd says: Symbol "setup_tabread40x7e_tild" not found (without 'e').

i don't get it. help appreciated.

roman





___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Mathieu Bouchard]

On Thu, 6 Dec 2007, Chris McCormick wrote:

On Thu, Dec 06, 2007 at 04:24:42PM -0500, Mathieu Bouchard wrote:

On Thu, 6 Dec 2007, Olivier Heinry wrote:

Moreover, the code has already been desired and written, "just" not been
implemented in vanilla.

excuse me, which version of pd really allows you to edit and save cord
segmentations?

Didn't I once see screenshots from you of patches that showed segmented
and spline curve patch chords?


They were all "fake" because they were runtime-generated in order to look 
funny, instead of being user-generated and savable in order to be useful. 
They could also be runtime-generated and be useful, but for those who have 
seen the 3 screenshots and the live demos, it was clearly on the funny 
side.


Nevertheless, wire segmentations are still on my todo list and if no-one 
does it for me then i'll do it one day :)


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd and max (2)

[Mathieu Bouchard]

On Thu, 6 Dec 2007, marius schebella wrote:

"find last error", even if this does not work all the time, it really 
helped me save a lot of time.


Btw, "find last error" in DesireData works pretty much all of the time.

In PureData, "find last error" relies on the good will of external (and 
internal) developers to use pd_error() instead of error(). In DesireData, 
pd_error() is obsolete and deprecated.


With a little more work, DesireData's "find last error" will be able to 
actually select all objects involved in the message chain leading to the 
error! e.g.:


[loadbang]
 |
[tgl]
 |
[metro 666]
 |
[f]
 |
[symbol]

would select the last three objects, because [metro]'s bang led to 0 which 
led to "no method for float". the start of the message chain is usually 
[metro], [delay], [gemhead] and other clock-driven classes (so [tgl] can't 
be found to be the ancestor of the error).


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.41.0 test07 font size

[Mathieu Bouchard]

On Fri, 7 Dec 2007, Roman Haefeli wrote:

On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote:

i'll get my wishlist engine running before soon with stuff like:
- 64bit-pd (that is, not just run pd on an amd64; but have
t_float/t_sample be *large*)

does that mean, that every float in pd on an 64bit machine will have
64bit precision? and each sample in a table uses 8 byte ram? does it
also mean, that there will be less [tabread4~] floating point rounding
issues (in other words: [tabread4~] sounds 'good' up to x minutes?)


A day of mono 96000 Hz sound at 64 bits per sample would take 61.8 gigs of 
RAM. This takes 33 bits of precision to address. This leaves 19 bits of 
between-samples precision for interpolation by [tabread4]. The precision 
of float64 is 52 bits, thus the number of significant bits is 53, still 
not counting the sign. Thus float64 completely includes uint53 and int54. 
This raises the counter problem's threshold to 9007199254740992.


And yes, it would use twice more RAM everywhere. This includes the cache, 
so it may cause slowdown in some situations. I would enjoy it if [table] 
and its friends supported int16 (mere CD quality) for example. I believe 
that in float64 mode, pd could benefit from a float32 option on [table] 
too.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] freeverb~ roomsize / damping not working

[patrick]

hi hans,

it's the freeverb~ from pd-extended using:

cd pure-data/packages/ && make patch
cd linux_make
make install

(a very recent  checkout-developer-layout.sh 
)

patrick


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[Hans-Christoph Steiner]

So now the next step is building a system that lets you have the ease  
of jitter with the flexibility of Pd :D

.hc

On Dec 6, 2007, at 5:42 PM, vade wrote:

> This is an interesting viewpoint -
>
> "at what point does providing all of these options just get in my  
> way and make me not think about creating my own solutions - and  
> thus really really making it mine - while extending my knowledge"
>
> Im not sure, I can tell you ive had to make plenty of my own  
> solutions with Max/Jitter - but I think you have a very valid  
> point. There certainly are a few assumptions on Jitters part that I  
> do not necessarily agree with.
>
> Well said.
>
>
> On Dec 6, 2007, at 4:10 PM, Hans-Christoph Steiner wrote:
>
>> I also think that megaobjects that accept many messages/attributes
>> become more like application preferences rather than programming, and
>> that usually limits the possibilities.





 


"Free software means you control what your computer does. Non-free  
software means someone else controls that, and to some extent  
controls you." - Richard M. Stallman



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] freeverb~ roomsize / damping not working

[Hans-Christoph Steiner]

Perhaps it's an aliasing bug, I know freeverb has some non-strick  
aliases.  Basically, you need to compiling it with less optimization.

How about the freeverb included in Pd-extended?

.hc

On Dec 6, 2007, at 8:54 PM, patrick wrote:

> hi,
>
> i compiled freeverb~ without any problem, but the controls are not
> modifying the sound. a theora video of the problem can be seen here:
>
> http://www.workinprogress.ca/pd/pdmtl/freeverbbug.ogg
> (vlc, mplayer etc...).
>
> i am on linux / pentium 4.
> freeverb~ v1.2
>
> pat
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


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



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Hans-Christoph Steiner]

On Dec 6, 2007, at 2:54 PM, Daniel Wilcox wrote:

Now there's an idea!  If some donations could be had to offer up  
bounty money, I'd say

a few more of us would be inclined to pitch in.


Patches welcome! ;)  Seriously, if anyone wants to set this up, I  
think it could work.  In the past, some people objected to the idea  
since they didn't think it's fair (check the archives).  I think it  
could be done fair if people are directly sponsored the work they  
wanted done.  Maybe there is a site that provides this service  
already?  Sourceforge has started something like that, but I don't  
know the details.



Also, has pd been in the Goggle Summer of Code?


Yup, there were two funded projects last summer.  The number of  
funded slots that google provides is directly related to how many  
project submissions there are, so next summer, we should really work  
together to make sure there are lots of submissions.  I mean we can  
actually help write the applications together on the list.


... I'm unfamiliar with the dev setup but have there been any  
"coding camps" where people get
together to just implement something, just do it for like a  
weekend?  It is always nice to tackle a problem
with someone to bounce ideas off of in person.  Couchsurfing.com,  
an online lend-your-couch travel
networking collective, has a week long code session every 6 months  
I believe. Of course the participants get
a free place to stay, etc but I don't see how something like that  
couldn't be sponsored for pd.


I think a coding camp is an awesome idea,  I would love that!  The  
problem for me is that there are few Pd people in the NYC area.  Or  
at least not so many who come to the patching circles that we run  
about every month or so.  If there was a way to bring more people to  
the patching circles, I am willing to make the effort.  For example,  
I can host people at my house.  Come January, I'll have a pull out  
bed, a mattress in the office, and even an inflatable mattress also.   
In addition, if it is during the early summer, I think I could  
organize rooms at the Polytechnic dorm for $40 a night, which is very  
cheap for NYC (the youth hostels are more).


Personally, I'd like to jump into some pd dev but I am no so sure  
where to start where it would be most effective (other then  
segmented patch cords :P).


I think it's best to work on something that you are interested in,  
but I'll happily make suggestions if you want. :-)


.hc




>>i read your mail as a pledge for a bounty system - is that right?

>>Am 06.12.2007 um 20:08 schrieb Kyle Klipowicz:

> And this is precisely the unfortunate reason why the open source  
world

> will (almost) always lag behind the commercial world of consumer
> software. When developers make their bread and butter based upon if
> the consumer buys, they're more likely to pay attention to and
> implement the wishes of their users. Take Ableton. They actively  
parse

> their online forums for feature requests...and then implement them
> when a critical mass is reached.
>
> There are some exceptions in the FOSS world. Ubuntu is quite user
> friendly (with the support of a large endowment from a very wealthy
> organization with a charter specifically devoted to bringing  
Linux to

> the non-programmer set of the world). Firefox is giving IE a run for
> it's money (although the primary codebase from FF comes from the old
> commercial, closed source Netscape).
>
> I know that Hans' statement re everyone becoming a developer is true
> in theory, but in reality people who want to rapidly prototype a
> project with something like Pd or Max are using these applications
> precisely because they do not want to code in C.
>
> After reading Marius' post re GEM vs. Jitter, it is painfully  
apparent

> that the capitalist/consumer model of software engineering has a few
> aspects to it that are difficult for the FOSS community to compete
> with. Namely monetary and human resources and the external  
pressure to
> meet the requests of the user in order to ensure a continuous  
flow of

> financial support. When you code for a hobby or yourself, it is
> difficult or even impossible to be bothered with these things, and
> rightly so. Without compensation, there's often little scope (or  
time)

> outside one's own projects for developers in the FOSS world. This is
> unfortunate, but as I see it, true.
>
> Question is, what can be done to change this or compete? Or  
should Pd

> just become the thing that hobbyist programmers use, while Max takes
> the stage as the "serious" tool for rapidly prototyping interactive
> A/V artworks? I hope that this is not the case...
>
> No flames meant in this mail, just compassionate thought-mulling.
>
> ~Kyle
>
>
> On Dec 6, 2007 1:21 AM, Frank Barknecht <[EMAIL PROTECTED]> wrote:
>
>> That's exactly the point: From this thread it seems that many of
>> those
>> people who would be able to implement segmented patchcords aren't
>> interested in t

[PD] freeverb~ roomsize / damping not working

[patrick]

hi,

i compiled freeverb~ without any problem, but the controls are not 
modifying the sound. a theora video of the problem can be seen here:

http://www.workinprogress.ca/pd/pdmtl/freeverbbug.ogg
(vlc, mplayer etc...).

i am on linux / pentium 4.
freeverb~ v1.2

pat

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD & MAX))

[Jack]

Le 6 déc. 07 à 22:05, Kyle Klipowicz a écrit :

> Yes, a bounty system would be great. At this point, if you are not a
> student, Max/MSP/Jitter costs about $850 US. I think that (myself
> included) many Pd users would gladly shell out a few dollars to see
> features met. I for one have donated to Hans' efforts directly on his
> site via PayPal, because I know of the importance of financial
> 'reinforcement.'
>
> What is Matju's bounty on getting gridflow working out of box on OS X?
It would be nice to have this library directly in pd-extended ! ;)
Or a great tutorial (How to install gridflow on osx for beginner ?)

Jack

>
> ~Kyle
>
> On Dec 6, 2007 2:05 PM, Frank Barknecht <[EMAIL PROTECTED]> wrote:
>> Hallo,
>> Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
>>
>>> And this is precisely the unfortunate reason why the open source  
>>> world
>>> will (almost) always lag behind the commercial world of consumer
>>> software. When developers make their bread and butter based upon if
>>> the consumer buys, they're more likely to pay attention to and
>>> implement the wishes of their users. Take Ableton. They actively  
>>> parse
>>> their online forums for feature requests...and then implement them
>>> when a critical mass is reached.
>>>
>>> There are some exceptions in the FOSS world. Ubuntu is quite user
>>> friendly (with the support of a large endowment from a very wealthy
>>> organization with a charter specifically devoted to bringing  
>>> Linux to
>>> the non-programmer set of the world). Firefox is giving IE a run for
>>> it's money (although the primary codebase from FF comes from the old
>>> commercial, closed source Netscape).
>>
>> Ubuntu, while open source, is a commercial product. Like Redhat Linux
>> and many other commercial FLOSS products. For these kinds of open
>> source software, money of course is one motivation, and if that money
>> comes directly from the user, the user's wishes are a influencing the
>> software more directly. Money is not a bad motivator, and it's even
>> playing a role in our little Pd world, where some projects are or  
>> have
>> been funded (like IIRC the early work by Hans on pd-extended, or many
>> docs, which were made for paid workshops etc.)
>>
>>
>>
>> Ciao
>> --
>>  Frank Barknecht _  
>> __footils.org__
>>
>> ___
>> PD-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>>
>
>
>
> -- 
> -
> 
>  -
>   - --
> http://perhapsidid.wordpress.com
> http://myspace.com/kyleklipowicz
>
> ___
> 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

Re: [PD] pd and max (2)

[Chris McCormick]

On Thu, Dec 06, 2007 at 07:45:41PM -0500, marius schebella wrote:
> * no licencing: that means you don't pay money to be allowed to program 
> in pd. (the player is free also in max). but it also means that you 
> don't have to fiddle around with the licence when you install (which 
> usually takes a day) or that you licence can expire or that you will 
> have to redo this when you buy new hardware.

In fact, Pd has such a free license that you can even fork it and make
your own closed-source commercial product out of it if you want. The
only requirement is that you include the license and copyright.

Best,

Chris.

---
http://mccormick.cx

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Chris McCormick]

On Thu, Dec 06, 2007 at 04:24:42PM -0500, Mathieu Bouchard wrote:
> On Thu, 6 Dec 2007, Olivier Heinry wrote:
> 
> >Moreover, the code has already been desired and written, "just" not been
> >implemented in vanilla.
> 
> excuse me, which version of pd really allows you to edit and save cord 
> segmentations?

Hi Matju,

Didn't I once see screenshots from you of patches that showed segmented
and spline curve patch chords?

Best,

Chris.

---
http://mccormick.cx

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.41.0 test07 font size

[Roman Haefeli]

On Fri, 2007-12-07 at 01:26 +0100, IOhannes m zmoelnig wrote:

> i'll get my wishlist engine running before soon with stuff like:
> - 64bit-pd (that is, not just run pd on an amd64; but have 
> t_float/t_sample be *large*)

does that mean, that every float in pd on an 64bit machine will have
64bit precision? and each sample in a table uses 8 byte ram? does it
also mean, that there will be less [tabread4~] floating point rounding
issues (in other words: [tabread4~] sounds 'good' up to x minutes?)

roman




___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd and max (2)

[marius schebella]

oh, forgot
"find last error", even if this does not work all the time, it really 
helped me save a lot of time.
plus "find" feature is also not implemented in max.
marius.

marius schebella wrote:
> hi,
> after all the complaining, here is a list of features that are special 
> to pd.
> * open source: you can always dig into the deep universe of code to see 
> how things are done. and change things according to your needs
> * no licencing: that means you don't pay money to be allowed to program 
> in pd. (the player is free also in max). but it also means that you 
> don't have to fiddle around with the licence when you install (which 
> usually takes a day) or that you licence can expire or that you will 
> have to redo this when you buy new hardware.
> * no messing around with floats and ints. no mistakes because you forget 
> a dot (for example in [/ 10.]) that also includes that you can create 
> arithmetic operators without arguments. whereas in max the default is 
> integer. which means you cannot just type [/].
> * possibility to edit abstractions! in max you always have to open the 
> abstraction itself which is more than annoying.
> * possibility to save your patch with an open subpatch window in the 
> front. (max thinks, you want to save the subpatch as a seperate new 
> patch...)
> * no list object (ok, there is [zl reg])
> * no [t a b]
> * as far as I know no settable sliders. (slider 200 will have a fixed 
> size and a fixed scale (0-199 - linear) (might be wrong with that).
> * no keyboard shortcuts to create objects/messages (ctl+1...). there is 
> a max toolbox, but that does not work reliable.
> unpack does not work for symbols in max. (but I am sure you can do that 
> somehow else)
> diffs: two things that are different in max: [trigger 5 b] takes 5 as a 
> number and not as a selector. when you bang it, even when you feed in 
> another int, it will still output 5 and not zero as in pd.
> messages also remember their last value that you sent through them, so 
> if you bang a message [$1 $2( it will spit out the last values and not
> 0 0. (only at the beginning as default)
> * max does not run on linux
> 
> ...
> 
> m.
> 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd and max (2)

[marius schebella]

hi,
after all the complaining, here is a list of features that are special 
to pd.
* open source: you can always dig into the deep universe of code to see 
how things are done. and change things according to your needs
* no licencing: that means you don't pay money to be allowed to program 
in pd. (the player is free also in max). but it also means that you 
don't have to fiddle around with the licence when you install (which 
usually takes a day) or that you licence can expire or that you will 
have to redo this when you buy new hardware.
* no messing around with floats and ints. no mistakes because you forget 
a dot (for example in [/ 10.]) that also includes that you can create 
arithmetic operators without arguments. whereas in max the default is 
integer. which means you cannot just type [/].
* possibility to edit abstractions! in max you always have to open the 
abstraction itself which is more than annoying.
* possibility to save your patch with an open subpatch window in the 
front. (max thinks, you want to save the subpatch as a seperate new 
patch...)
* no list object (ok, there is [zl reg])
* no [t a b]
* as far as I know no settable sliders. (slider 200 will have a fixed 
size and a fixed scale (0-199 - linear) (might be wrong with that).
* no keyboard shortcuts to create objects/messages (ctl+1...). there is 
a max toolbox, but that does not work reliable.
unpack does not work for symbols in max. (but I am sure you can do that 
somehow else)
diffs: two things that are different in max: [trigger 5 b] takes 5 as a 
number and not as a selector. when you bang it, even when you feed in 
another int, it will still output 5 and not zero as in pd.
messages also remember their last value that you sent through them, so 
if you bang a message [$1 $2( it will spit out the last values and not
0 0. (only at the beginning as default)
* max does not run on linux

...

m.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD & MAX))

[Dafydd Hughes]

hey...

On Dec 6, 2007 5:50 PM, marius schebella <[EMAIL PROTECTED]> wrote:
> Kyle Klipowicz wrote:
> > I for one have donated to Hans' efforts directly on his
> > site via PayPal,
>
> now it's out, YOU were the one...
> marius.
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>



-- 
www.sideshowmedia.ca
skype: chickeninthegrass

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.41.0 test07 font size

[IOhannes m zmoelnig]

Miller Puckette wrote:
> Well, not much has happened, but the test version is stable enough it
> seems better to work toward a "stable" version of teh present state than
> to try to add all the features I want to put in next :)

that sounds even better!

i'll get my wishlist engine running before soon with stuff like:
- user defined atom-types
- a better saving hook including
- somehow moving "open abstraction" into sys_loadlib chain
- 64bit-pd (that is, not just run pd on an amd64; but have 
t_float/t_sample be *large*)
- ..
- and all rest i cannot think of right now


fg,adf
IOhannes




___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.41.0 test07 font size

[Miller Puckette]

Well, not much has happened, but the test version is stable enough it
seems better to work toward a "stable" version of teh present state than
to try to add all the features I want to put in next :)

M

On Fri, Dec 07, 2007 at 01:17:19AM +0100, IOhannes m zmoelnig wrote:
> Miller Puckette wrote:
> > OK test09, hopefully, fixes it :)
> > 
> > I've got a long list of bugs to try to fix... otherwise I'm probably
> > not going to try to add any more "features" to this release before
> > canning it.
> 
> i have jut assigned you some more patches in the patchtracker at 
> sourceforge...;-)
> 
> so this basically means that we will get a new pd-version soon? great!
> 
> 
> 
> fmfadt.
> 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

Re: [PD] pd 0.41.0 test07 font size

[IOhannes m zmoelnig]

Miller Puckette wrote:
> OK test09, hopefully, fixes it :)
> 
> I've got a long list of bugs to try to fix... otherwise I'm probably
> not going to try to add any more "features" to this release before
> canning it.

i have jut assigned you some more patches in the patchtracker at 
sourceforge...;-)

so this basically means that we will get a new pd-version soon? great!



fmfadt.
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[marius schebella]

I have no idea how complicated this stuff really is. from the user's 
viewpoint it looked like some lines of code, that needed to be added.
and I know that it is even harder if you are alone in your problem 
solving...
marius.

chris clepper wrote:
> On Dec 6, 2007 10:46 AM, marius schebella <[EMAIL PROTECTED]>
> wrote:
> 
>> no real multitexture support for opengl. that is a must, if you want to
>> work with shader languages like glsl.
> 
> 
> Multitexturing works fine.  The only drawback is that only texcoords from
> the texture unit in the chain with the shader can be used.  This only
> presents a problem if the texture dimensions are different sizes.
> 
> 
>> this should be easily fixed by someone with sufficiant knowledge of the
>> opengl world and gem (and time and resources...).
> 
> 
> Unfortunately it is either not easy to fix or just beyond my abilities to do
> so.  I have spent many, many hours trying to get this to work but cannot
> make it so.
> 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.41.0 test07 font size

[cyrille henry]

hello,
yes, test 09 look good. whatever the screen resolution is.
(at least on my ubuntu computer)
thanks
Cyrille


Miller Puckette a écrit :
> OK test09, hopefully, fixes it :)
> 
> I've got a long list of bugs to try to fix... otherwise I'm probably
> not going to try to add any more "features" to this release before
> canning it.
> 
> cheers
> Miller
> 
> On Fri, Nov 23, 2007 at 07:04:25PM +0100, cyrille henry wrote:
>> hello,
>>
>> test 08 is better, but not perfect : 
>> - the font of the objects are the same whatever the screen size -> ok
>> - the font size of text in the main pd window is still change
>> - the font size of the comment (canvas label) that i use in the _gemwin gop 
>> abstraction are also changing.
>>
>> should i upload new snapshot?
>>
>> thanks,
>> Cyrille
> 
> ___
> 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

Re: [PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD & MAX))

[marius schebella]

Kyle Klipowicz wrote:
> I for one have donated to Hans' efforts directly on his
> site via PayPal, 

now it's out, YOU were the one...
marius.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[vade]

This is an interesting viewpoint -

"at what point does providing all of these options just get in my way  
and make me not think about creating my own solutions - and thus  
really really making it mine - while extending my knowledge"

Im not sure, I can tell you ive had to make plenty of my own solutions  
with Max/Jitter - but I think you have a very valid point. There  
certainly are a few assumptions on Jitters part that I do not  
necessarily agree with.

Well said.


On Dec 6, 2007, at 4:10 PM, Hans-Christoph Steiner wrote:

> I also think that megaobjects that accept many messages/attributes
> become more like application preferences rather than programming, and
> that usually limits the possibilities.


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd 0.41.0 test07 font size

[Miller Puckette]

OK test09, hopefully, fixes it :)

I've got a long list of bugs to try to fix... otherwise I'm probably
not going to try to add any more "features" to this release before
canning it.

cheers
Miller

On Fri, Nov 23, 2007 at 07:04:25PM +0100, cyrille henry wrote:
> hello,
> 
> test 08 is better, but not perfect : 
> - the font of the objects are the same whatever the screen size -> ok
> - the font size of text in the main pd window is still change
> - the font size of the comment (canvas label) that i use in the _gemwin gop 
> abstraction are also changing.
> 
> should i upload new snapshot?
> 
> thanks,
> Cyrille

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[chris clepper]

On Dec 6, 2007 10:46 AM, marius schebella <[EMAIL PROTECTED]>
wrote:

>
> no real multitexture support for opengl. that is a must, if you want to
> work with shader languages like glsl.


Multitexturing works fine.  The only drawback is that only texcoords from
the texture unit in the chain with the shader can be used.  This only
presents a problem if the texture dimensions are different sizes.


> this should be easily fixed by someone with sufficiant knowledge of the
> opengl world and gem (and time and resources...).


Unfortunately it is either not easy to fix or just beyond my abilities to do
so.  I have spent many, many hours trying to get this to work but cannot
make it so.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Mathieu Bouchard]

On Thu, 6 Dec 2007, Olivier Heinry wrote:


Moreover, the code has already been desired and written, "just" not been
implemented in vanilla.


excuse me, which version of pd really allows you to edit and save cord 
segmentations?


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[Hans-Christoph Steiner]

I also think that megaobjects that accept many messages/attributes  
become more like application preferences rather than programming, and  
that usually limits the possibilities.  For example, in C, a function  
with more than 5 parameters starts to get quite ugly and unwieldy.   
In LISP, which Max's list handling is modeled after, it is also not  
good form to have many attributes in a single function.   
Objectclasses in object-oriented languages like Java, etc. accept  
many messages, but I think that Max is more like a functional  
language than an object-oriented one, (but somewhere in between).

I'm not saying I have the answer (yet? :) but this for me, thinking  
about these kinds of things makes for a more intuitive and fluid  
programming language.

(and when I say "Max" here, I am talking Max family, which includes Pd).

.hc

On Dec 6, 2007, at 2:38 PM, vade wrote:

> You can do both within jitter, anything that is an attribute is by  
> virtue of being an attribute also a message - so you can send it  
> via loadbang, loadmess or whenever/however you want, so its up to  
> you to choose how you want your patch to work :)
>
> On Dec 6, 2007, at 2:16 PM, Hans-Christoph Steiner wrote:
>
>> icely said, hopefully you can drum up more support for Gem.  One
>> thing I think it really great about Gem is that is remains strongly
>> visual.  When getting heavy into jitter, the patches look like you
>> are writing in C++ with boxes around it.  What I would really like to
>> see is all those naming and attribute features represented in a
>> visual way, rather than just long lines of text like in Jitter.  THen
>> if you want to write text-based code, you can use luagl, etc.



 


All information should be free.  - the hacker ethic





___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Bounties for Pd Features (was RE: segmented patchcords (was Re: PD & MAX))

[Kyle Klipowicz]

Yes, a bounty system would be great. At this point, if you are not a
student, Max/MSP/Jitter costs about $850 US. I think that (myself
included) many Pd users would gladly shell out a few dollars to see
features met. I for one have donated to Hans' efforts directly on his
site via PayPal, because I know of the importance of financial
'reinforcement.'

What is Matju's bounty on getting gridflow working out of box on OS X?

~Kyle

On Dec 6, 2007 2:05 PM, Frank Barknecht <[EMAIL PROTECTED]> wrote:
> Hallo,
> Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:
>
> > And this is precisely the unfortunate reason why the open source world
> > will (almost) always lag behind the commercial world of consumer
> > software. When developers make their bread and butter based upon if
> > the consumer buys, they're more likely to pay attention to and
> > implement the wishes of their users. Take Ableton. They actively parse
> > their online forums for feature requests...and then implement them
> > when a critical mass is reached.
> >
> > There are some exceptions in the FOSS world. Ubuntu is quite user
> > friendly (with the support of a large endowment from a very wealthy
> > organization with a charter specifically devoted to bringing Linux to
> > the non-programmer set of the world). Firefox is giving IE a run for
> > it's money (although the primary codebase from FF comes from the old
> > commercial, closed source Netscape).
>
> Ubuntu, while open source, is a commercial product. Like Redhat Linux
> and many other commercial FLOSS products. For these kinds of open
> source software, money of course is one motivation, and if that money
> comes directly from the user, the user's wishes are a influencing the
> software more directly. Money is not a bad motivator, and it's even
> playing a role in our little Pd world, where some projects are or have
> been funded (like IIRC the early work by Hans on pd-extended, or many
> docs, which were made for paid workshops etc.)
>
>
>
> Ciao
> --
>  Frank Barknecht _ __footils.org__
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>



-- 
-

 -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Object to store images and movies.

[Mike McGonagle]

On 12/5/07, Derek Holzer <[EMAIL PROTECTED]> wrote:
>
> If you are using GEM, then look at [pix_image], [pix_film] and
> [pix_movie]. You'll need to develop some sort of rudimentary "database"
> to catalog and access the images and clips, of course...
>

As far as the Database stuff goes, if you would like, please check out the
SQLite external. It is posted on the Pure Data website at (
http://puredata.info/Members/mjmogo ). While it is still under developement,
it is quite usable. It still doesn't have support for storing Blob kinds of
data, but this would be a good time to discuss adding those features.

(Sorry to go off topic, but this might be something that helps to change
what I see as a lack in PD. A coherent, simple means of storing and
retrieving data.)

Mike
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] italian infobox

[Fabio Buda [mbutUbuntu]]

hello folks,
I've just translated the Firts Page of the italian wiki...

here there is the IT translation of infobox
# wikipedia terms
$stub = "matrice";
$template = "modello";
$category = "categoria";
$infobox = "casella informativa";
 
# pdpedia terms
$objectclass = "classe di oggetti";
 
# page headers
$inlets = "ingressi";
$outlets = "uscite";
$arguments = "argomenti";
$messages = "messaggi";
 
# infobox
$name = "nome";
$description = "descrizione";
$abbreviation = "abbreviazione";
$example image = "immagine d'esempio";
$caption = "didascalia";
$library = "libreria";
$author = "autore";
$developer = "sviluppatore";
$releaseVersion = "versione di rilascio";
$releaseDate = "data di rilascio";
$status = "stato";
$dependencies = "dipendenze";
$license = "licenza";
$website = "sito web";
$programmingLanguage = "linguaggio di programmazione";
$platform = "piattaforma";
$operatingSystem = "sistema operativo";
$language = "lingua";
$dataType = "tipo di dati";
$distribution = "distribuzione";

# proposed additions
$helppatch name = "";
$cpu use index = "indice di utilizzo della cpu";
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Object to store images and movies.

[Donal Carey]

Thanks for all the info guys - will post the patch up if I get it working.

Cheers
Donal


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Meaning of -noprefs

[Peter Plessas]

Hi,

> I think "-noprefs" should stop .pdrc as well, since it's in the spirit
that is great news! Btw, is there a document on the available options in 
.pdsettings?

For example:
Does "defeatrt: 0" imply -rt?
Otherwise, how does one set -rt?
Which Audio-API is which number?

Let me take the opportunity to address two other issues, both already
discussed a lot on the list but still worthy to address:

Hiding hidden folders in Tcl's file dialog. (1)
The position of objects being pasted into a patcher. (2)

After almost five years of working with pd a lot, these two things are
the ones, that bother users (like me) the most. They might be hard to
solve, but are still necessary to solve.
One can live without much eye-candy and other 'nice-to-have' features very 
well. 
But those two things are an obstacle to everyday work in pd, because (1)
is slowing the work down, and (2) is causing confusion.

thanks & regards from

Peter 

* Miller Puckette <[EMAIL PROTECTED]> [2007-12-05 23:46]:
> Hi all,
> 
> I think "-noprefs" should stop .pdrc as well, since it's in the spirit
> of being able to find out whether a problem is coming from the configuration
> or from Pd itself.  If it's reasonably easy to do I'll change that.
> 
> That said, I think ".pdrc" should be regarded as deprecated, unless there's
> something you can do with it that can't be done in .pdsettings instead.
> 
> cheers
> Miller
> 
> On Wed, Dec 05, 2007 at 09:31:31AM +0100, Peter Plessas wrote:
> > Dear List, Simon
> > 
> > Thanks Simon for your kind reply and explanations
> > 
> > So although there might be space for calling that behavior an additional 
> > but questionable 'feature', i consider it an inconsistency in user 
> > interface design. Preferences are preferences, whether they are in a 
> > .pdrc file or in a preferences file.
> > 
> > IMHO -noprefs should disable all preferences-mechanisms.
> > 
> > Regards,
> > 
> > Peter
> > 
> > simon wise wrote:
> > > 
> > > On 1 Dec 2007, at 10:11 PM, Peter Plessas wrote:
> > > 
> > >> i thought that the -noprefs flag also disables loading of the .pdrc file
> > >>   on linux, but it does not. Is this intentional on 0.40-2?
> > > 
> > > Since the preference dialogues were added they have always been treated 
> > > as quite separate from the older .pdrc system - IMHO this split remains 
> > > useful as it is possible to either ignore the older system (just delete 
> > > any .pdrc files) or use it instead (delete the settings files instead) 
> > > or use both in parallel to help manage your settings in different ways 
> > > for different circumstances (eg using the .pdrc to set up machine 
> > > specific things like which soundcard to use while selecting libraries 
> > > and startup patches with the preferences). The newer preference system 
> > > is getting some very useful features - especially the embedded option! - 
> > > and when the dialogue box eventually gets more than 10 slots I will use 
> > > the .pdrc system less often.
> > > 
> > > simon
> > > 
> > > 
> > 
> > ___
> > 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

Re: [PD] segmented patchcords (was Re: PD & MAX)

[chris clepper]

If I were running a commercial software firm and software made by random
people in their spare time compared pretty well with my pricey software, I
would be a little concerned.

On Dec 6, 2007 1:08 PM, Kyle Klipowicz <[EMAIL PROTECTED]> wrote:

> And this is precisely the unfortunate reason why the open source world
> will (almost) always lag behind the commercial world of consumer
> software. When developers make their bread and butter based upon if
> the consumer buys, they're more likely to pay attention to and
> implement the wishes of their users. Take Ableton. They actively parse
> their online forums for feature requests...and then implement them
> when a critical mass is reached.
>
> There are some exceptions in the FOSS world. Ubuntu is quite user
> friendly (with the support of a large endowment from a very wealthy
> organization with a charter specifically devoted to bringing Linux to
> the non-programmer set of the world). Firefox is giving IE a run for
> it's money (although the primary codebase from FF comes from the old
> commercial, closed source Netscape).
>
> I know that Hans' statement re everyone becoming a developer is true
> in theory, but in reality people who want to rapidly prototype a
> project with something like Pd or Max are using these applications
> precisely because they do not want to code in C.
>
> After reading Marius' post re GEM vs. Jitter, it is painfully apparent
> that the capitalist/consumer model of software engineering has a few
> aspects to it that are difficult for the FOSS community to compete
> with. Namely monetary and human resources and the external pressure to
> meet the requests of the user in order to ensure a continuous flow of
> financial support. When you code for a hobby or yourself, it is
> difficult or even impossible to be bothered with these things, and
> rightly so. Without compensation, there's often little scope (or time)
> outside one's own projects for developers in the FOSS world. This is
> unfortunate, but as I see it, true.
>
> Question is, what can be done to change this or compete? Or should Pd
> just become the thing that hobbyist programmers use, while Max takes
> the stage as the "serious" tool for rapidly prototyping interactive
> A/V artworks? I hope that this is not the case...
>
> No flames meant in this mail, just compassionate thought-mulling.
>
> ~Kyle
>
>
>
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Frank Barknecht]

Hallo,
Kyle Klipowicz hat gesagt: // Kyle Klipowicz wrote:

> And this is precisely the unfortunate reason why the open source world
> will (almost) always lag behind the commercial world of consumer
> software. When developers make their bread and butter based upon if
> the consumer buys, they're more likely to pay attention to and
> implement the wishes of their users. Take Ableton. They actively parse
> their online forums for feature requests...and then implement them
> when a critical mass is reached.
> 
> There are some exceptions in the FOSS world. Ubuntu is quite user
> friendly (with the support of a large endowment from a very wealthy
> organization with a charter specifically devoted to bringing Linux to
> the non-programmer set of the world). Firefox is giving IE a run for
> it's money (although the primary codebase from FF comes from the old
> commercial, closed source Netscape).

Ubuntu, while open source, is a commercial product. Like Redhat Linux
and many other commercial FLOSS products. For these kinds of open
source software, money of course is one motivation, and if that money
comes directly from the user, the user's wishes are a influencing the
software more directly. Money is not a bad motivator, and it's even
playing a role in our little Pd world, where some projects are or have
been funded (like IIRC the early work by Hans on pd-extended, or many
docs, which were made for paid workshops etc.)


Ciao
-- 
 Frank Barknecht _ __footils.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[Mathieu Bouchard]

On Thu, 6 Dec 2007, vade wrote:

well, FYI in Jitter you do [jit.someobject @color r g b a] (for 
example), or can use a message named color. Ive never seen or used 
[jit.someobject @red r @green g @blue b @alpha a]


I forgot to say that it applies only to some of the classes in Jitter.

For example:

  http://cycling74.com/documentation/jit.eclipse

I haven't looked at how many classes do it like that for the colours, but 
also some classes treat x and y axes as separate attributes instead of 
together, for example.


I quite like the attribute system jitter has, and think it could be imported 
with some sort of syntax highlighting for objects where attribute names are 
one color and their set values another.


So far I'm ok with the attribute system of GridFlow; Flext users seem ok 
with the attribute system of Flext; and the syntax is already mostly 
enough: the comma of GridFlow and the at-sign of Flext are distinctive 
enough. Colouring is not much of an addition because the text-based syntax 
of pd/max is too simple for that. (pd/max's syntax is more patch-based 
than text-based).



It would (may?) help visually grokking the text within the patcher object


"grok" should be reserved for what it originally meant, which is more 
intense than "understanding how it works", let alone "being able to parse 
the text". I'd love it if just the colours were enough to communicate the 
totality of the meaning of pd :} but it's not going to happen.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Daniel Wilcox]

Now there's an idea!  If some donations could be had to offer up bounty
money, I'd say
a few more of us would be inclined to pitch in.  Also, has pd been in the
Goggle Summer of Code?
... I'm unfamiliar with the dev setup but have there been any "coding camps"
where people get
together to just implement something, just do it for like a weekend?  It is
always nice to tackle a problem
with someone to bounce ideas off of in person.  Couchsurfing.com, an online
lend-your-couch travel
networking collective, has a week long code session every 6 months I
believe. Of course the participants get
a free place to stay, etc but I don't see how something like that couldn't
be sponsored for pd.

Personally, I'd like to jump into some pd dev but I am no so sure where to
start where it would be most effective (other then segmented patch cords
:P).

>>i read your mail as a pledge for a bounty system - is that right?

>>Am 06.12.2007 um 20:08 schrieb Kyle Klipowicz:

> And this is precisely the unfortunate reason why the open source world
> will (almost) always lag behind the commercial world of consumer
> software. When developers make their bread and butter based upon if
> the consumer buys, they're more likely to pay attention to and
> implement the wishes of their users. Take Ableton. They actively parse
> their online forums for feature requests...and then implement them
> when a critical mass is reached.
>
> There are some exceptions in the FOSS world. Ubuntu is quite user
> friendly (with the support of a large endowment from a very wealthy
> organization with a charter specifically devoted to bringing Linux to
> the non-programmer set of the world). Firefox is giving IE a run for
> it's money (although the primary codebase from FF comes from the old
> commercial, closed source Netscape).
>
> I know that Hans' statement re everyone becoming a developer is true
> in theory, but in reality people who want to rapidly prototype a
> project with something like Pd or Max are using these applications
> precisely because they do not want to code in C.
>
> After reading Marius' post re GEM vs. Jitter, it is painfully apparent
> that the capitalist/consumer model of software engineering has a few
> aspects to it that are difficult for the FOSS community to compete
> with. Namely monetary and human resources and the external pressure to
> meet the requests of the user in order to ensure a continuous flow of
> financial support. When you code for a hobby or yourself, it is
> difficult or even impossible to be bothered with these things, and
> rightly so. Without compensation, there's often little scope (or time)
> outside one's own projects for developers in the FOSS world. This is
> unfortunate, but as I see it, true.
>
> Question is, what can be done to change this or compete? Or should Pd
> just become the thing that hobbyist programmers use, while Max takes
> the stage as the "serious" tool for rapidly prototyping interactive
> A/V artworks? I hope that this is not the case...
>
> No flames meant in this mail, just compassionate thought-mulling.
>
> ~Kyle
>
>
> On Dec 6, 2007 1:21 AM, Frank Barknecht <[EMAIL PROTECTED]> wrote:
>
>> That's exactly the point: From this thread it seems that many of
>> those
>> people who would be able to implement segmented patchcords aren't
>> interested in that feature. (You'd be one of the exceptions.) So
>> until
>> someone comes along who wants seg-cords in Pd and at the same time
>> could write the code, the feature stays missing. That's not unusual
>> wiht open source software: features, the developers need, get
>> implemented faster, others maybe never.
>
> --
> -
> 
>  -
>   - --
> http://perhapsidid.wordpress.com
> http://myspace.com/kyleklipowicz
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list




___
PD-list mailing list
PD-list@iem.at
to manage your subscription (including un-subscription) see
http://lists.puredata.info/listinfo/pd-list


-- 
Dan Wilcox
danomatika
www.robotcowboy.com
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[vade]

You can do both within jitter, anything that is an attribute is by  
virtue of being an attribute also a message - so you can send it via  
loadbang, loadmess or whenever/however you want, so its up to you to  
choose how you want your patch to work :)

On Dec 6, 2007, at 2:16 PM, Hans-Christoph Steiner wrote:

> icely said, hopefully you can drum up more support for Gem.  One
> thing I think it really great about Gem is that is remains strongly
> visual.  When getting heavy into jitter, the patches look like you
> are writing in C++ with boxes around it.  What I would really like to
> see is all those naming and attribute features represented in a
> visual way, rather than just long lines of text like in Jitter.  THen
> if you want to write text-based code, you can use luagl, etc.


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Max Neupert]

i read your mail as a pledge for a bounty system - is that right?


Am 06.12.2007 um 20:08 schrieb Kyle Klipowicz:

> And this is precisely the unfortunate reason why the open source world
> will (almost) always lag behind the commercial world of consumer
> software. When developers make their bread and butter based upon if
> the consumer buys, they're more likely to pay attention to and
> implement the wishes of their users. Take Ableton. They actively parse
> their online forums for feature requests...and then implement them
> when a critical mass is reached.
>
> There are some exceptions in the FOSS world. Ubuntu is quite user
> friendly (with the support of a large endowment from a very wealthy
> organization with a charter specifically devoted to bringing Linux to
> the non-programmer set of the world). Firefox is giving IE a run for
> it's money (although the primary codebase from FF comes from the old
> commercial, closed source Netscape).
>
> I know that Hans' statement re everyone becoming a developer is true
> in theory, but in reality people who want to rapidly prototype a
> project with something like Pd or Max are using these applications
> precisely because they do not want to code in C.
>
> After reading Marius' post re GEM vs. Jitter, it is painfully apparent
> that the capitalist/consumer model of software engineering has a few
> aspects to it that are difficult for the FOSS community to compete
> with. Namely monetary and human resources and the external pressure to
> meet the requests of the user in order to ensure a continuous flow of
> financial support. When you code for a hobby or yourself, it is
> difficult or even impossible to be bothered with these things, and
> rightly so. Without compensation, there's often little scope (or time)
> outside one's own projects for developers in the FOSS world. This is
> unfortunate, but as I see it, true.
>
> Question is, what can be done to change this or compete? Or should Pd
> just become the thing that hobbyist programmers use, while Max takes
> the stage as the "serious" tool for rapidly prototyping interactive
> A/V artworks? I hope that this is not the case...
>
> No flames meant in this mail, just compassionate thought-mulling.
>
> ~Kyle
>
>
> On Dec 6, 2007 1:21 AM, Frank Barknecht <[EMAIL PROTECTED]> wrote:
>
>> That's exactly the point: From this thread it seems that many of  
>> those
>> people who would be able to implement segmented patchcords aren't
>> interested in that feature. (You'd be one of the exceptions.) So  
>> until
>> someone comes along who wants seg-cords in Pd and at the same time
>> could write the code, the feature stays missing. That's not unusual
>> wiht open source software: features, the developers need, get
>> implemented faster, others maybe never.
>
> -- 
> -
> 
>  -
>   - --
> http://perhapsidid.wordpress.com
> http://myspace.com/kyleklipowicz
>
> ___
> 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

Re: [PD] Max & Pd

[vade]

well, FYI in Jitter you do [jit.someobject @color r g b a] (for  
example), or can use a message named color.

Ive never seen or used [jit.someobject @red r @green g @blue b @alpha a]

and jitter also has just about every colorspace conversion possible,  
that I have ever seen or dealt with professionally, and many I have  
not heard of or ever had to use:

http://cycling74.com/documentation/jit.colorspace

Not meant as flame bait (sorry, I still feel like an ass for yesterday  
Mathieu!), but more for compare/contrast.

I quite like the attribute system jitter has, and think it could be  
imported with some sort of syntax highlighting for objects where  
attribute names are one color and their set values another.

It would (may?) help visually grokking the text within the patcher  
object

On Dec 6, 2007, at 2:16 PM, Mathieu Bouchard wrote:

> On Thu, 6 Dec 2007, marius schebella wrote:
>
>> the most obvious and useful things are the tons of @arguments that  
>> each
>> objects accepts.
>
> Having tons of @arguments is not necessarily a blessing. Wherever  
> Jitter has four @arguments named red,green,blue,alpha, GridFlow has  
> only one, which is a list of the four colour components after a  
> [#pack]. It makes GridFlow more structured than Jitter in this case,  
> and that makes some objects more open to different colour spaces  
> than Jitter's, in addition to yielding a better features-per- 
> @arguments ratio.
>
> _ _ __ ___ _  _ _ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC  
> Canada___
> 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

Re: [PD] Max & Pd

[Hans-Christoph Steiner]

Nicely said, hopefully you can drum up more support for Gem.  One  
thing I think it really great about Gem is that is remains strongly  
visual.  When getting heavy into jitter, the patches look like you  
are writing in C++ with boxes around it.  What I would really like to  
see is all those naming and attribute features represented in a  
visual way, rather than just long lines of text like in Jitter.  THen  
if you want to write text-based code, you can use luagl, etc.

There are a lot of hidden secrets in Gem, you can do a lot with it.   
For example, you can use all of the OpenGL primitives, check out Help- 
 >Browser->examples->Gem->09.opengGL  Just having better docs and  
more examples would go a long way.

And I agree, Chris and IOhannes have been doing great work for a long  
time, and I don't think it's properly recognized.

.hc

On Dec 6, 2007, at 11:46 AM, marius schebella wrote:

> Hi Andrew,
> I use both. I am in a graduate class at brooklyn polytech, where josh
> goldberg teaches real time video interaction. it is an advanced class,
> and there are only 6 people, 3 of them are passionate  
> ("professional"?)
> jitter users, and 2 people started using max in this program, but are
> also using other real time programs (or write their own C/Java/ 
> whatever
> code) plus me. It is not a dedicated max class, but max gets the
> greatest support.
> I really tried hard to stay with Pd and do everything in GEM+...  
> but at
> some point this year I realized that GEM is not at all that highly
> developed as max and jitter.
> the most obvious and useful things are the tons of @arguments that  
> each
> objects accepts. then, with pwindow you always have small control
> windows inside your patch. all textures can be referenced by giving a
> @name attribute. you can switch easily between matrix computation  
> and gl
> world. you have better scripting support, plus more addons.
> the problem with gem, as I mentioned already on the list, is that it
> does not have enough developers. only iohannes and chris clepper are
> working on it, and it is more maintenance, than active developing.
> myself I am trying hard to get into GEM development, but it takes time
> until I know enough to be able to do that.
> the limitations of GEM at the moment are:
> no real multitexture support for opengl. that is a must, if you  
> want to
> work with shader languages like glsl.
> (jitter has that plus also javascript to combine the shaders, which in
> pd you have to do by patching.)
> this should be easily fixed by someone with sufficiant knowledge of  
> the
> opengl world and gem (and time and resources...). wesley, who is  
> also on
> this list, but also developing for c74, wrote the lua objects for
> jitter, and pdlua should be able to do equivalent stuff on pd-side for
> that (I am working to get it included into pd-extended.) I could  
> imagine
> that luagl people would rather use pd than max, because of open  
> source.
> on osx 10.5 the GEM window doesnot come to the front and does not  
> accept
> mouseclicks.
> I experienced problems with the colorspace on osx with some  
> pix_obects.
> on the other side jitter comes with a huge set of externals and
> abstractions. cv.jit is a great additional resource. but there are  
> tons...
> jitter has the more lively user community and you have more  
> developers.
>
> both programs lack of good vector graphics handling objects (like
> flash). this is a big lack in the open source world. a web savy open
> source replacement for flash!!!
>
> still, my heart beats for the open source community, so I would  
> like to
> see gem and pd do the same things (and more) than max and jitter  
> can do.
> If you work in longtime installations you want to use linux and gem.
> opengl/gem on linux is faster than anything else (well at least faster
> than max/jitter). os x graphics drivers even limit some features of  
> the
> gfx card for compatibility reasons...
>
> for the next 3 years at least, gem will be behind, and if there are no
> new coders that will not change. I am not sure if this will change
> without money getting involved. the only other possibility to get  
> people
> involved is teaching pd/gem at college level. and get student
> programmers involved. or grab some money for gem development. google
> summer of code, or grants...
>
> above all that, there are all still the "obvious" pro/cons of max  
> vs pd.
> marius.
>
> Andrew Brouse wrote:
>> Hello Pd and Max folks,
>>
>> I am doing a presentation (tomorrow!... so this request is a bit  
>> late!) on
>> differences between Max and Pd as tools for music and media art.
>>
>> I am interested in hearing:
>>
>> 1. from people who actively use both
>>
>> 2. about less-obvious advantages/disadvantages of one or the other
>>
>> 3. specifically about functionality for manipulation of video, OpenGL
>> including shaders and matricial data
>>
>> 4. clear, reasoned, articulate thoughts and arguments as to why  
>> one or

Re: [PD] making an Italian Version of pdpedia

[Hans-Christoph Steiner]

The next steps are outlined here:

http://wiki.puredata.info/en/Wiki_administrator_how-to

Post to the list if you have any questions.

.hc

On Dec 6, 2007, at 12:04 PM, Fabio Buda [mbutUbuntu] wrote:

> Ok, my username on the IT wiki is mbutubuntu.
> I'll contact also groups you say...
>
> Thank you
>
> Fabio [mbutubuntu] Buda
>
>
> Il giorno gio, 06/12/2007 alle 11.22 -0500, Hans-Christoph Steiner ha
> scritto:
>> Just ask! :D  I made the IT wiki, now create an account in it, and
>> post your username here.  Then I can make it admin:
>>
>> http://pdpedia.org/
>>
>> I don't know if you have any contact with this group, but it looks
>> like it would be good to get them to help too:
>>
>> http://puredata.bugslab.net/
>> http://www.digicult.it/digimag/article.asp?id=901
>>
>> .hc
>>
>>
>> On Dec 6, 2007, at 7:43 AM, Fabio Buda [mbutUbuntu] wrote:
>>
>>> Hello folks,
>>> I'm Fabio Buda and I study Electronic Music at "Istituto Musicale V.
>>> Bellini" of Catania (Sicily). I'd like to create an Italian Wiki of
>>> pdpedia: what can I do?
>>>
>>> Thanks
>>>
>>> Fabio [mbutUbuntu] Buda
>>>
>>>
>>>
>>>
>>> ___
>>> PD-list@iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>>> listinfo/pd-list
>>
>>
>>
>> - 
>> ---
>> 
>>
>> If nature has made any one thing less susceptible than all others of
>> exclusive property, it is the action of the thinking power called an
>> idea, which an individual may exclusively possess as long as he keeps
>> it to himself; but the moment it is divulged, it forces itself into
>> the possession of everyone, and the receiver cannot dispossess
>> himself of it.- Thomas Jefferson
>>
>>



 


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



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[Mathieu Bouchard]

On Thu, 6 Dec 2007, marius schebella wrote:


the most obvious and useful things are the tons of @arguments that each
objects accepts.


Having tons of @arguments is not necessarily a blessing. Wherever Jitter 
has four @arguments named red,green,blue,alpha, GridFlow has only one, 
which is a list of the four colour components after a [#pack]. It makes 
GridFlow more structured than Jitter in this case, and that makes some 
objects more open to different colour spaces than Jitter's, in addition to 
yielding a better [EMAIL PROTECTED] ratio.


 _ _ __ ___ _  _ _ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Kyle Klipowicz]

And this is precisely the unfortunate reason why the open source world
will (almost) always lag behind the commercial world of consumer
software. When developers make their bread and butter based upon if
the consumer buys, they're more likely to pay attention to and
implement the wishes of their users. Take Ableton. They actively parse
their online forums for feature requests...and then implement them
when a critical mass is reached.

There are some exceptions in the FOSS world. Ubuntu is quite user
friendly (with the support of a large endowment from a very wealthy
organization with a charter specifically devoted to bringing Linux to
the non-programmer set of the world). Firefox is giving IE a run for
it's money (although the primary codebase from FF comes from the old
commercial, closed source Netscape).

I know that Hans' statement re everyone becoming a developer is true
in theory, but in reality people who want to rapidly prototype a
project with something like Pd or Max are using these applications
precisely because they do not want to code in C.

After reading Marius' post re GEM vs. Jitter, it is painfully apparent
that the capitalist/consumer model of software engineering has a few
aspects to it that are difficult for the FOSS community to compete
with. Namely monetary and human resources and the external pressure to
meet the requests of the user in order to ensure a continuous flow of
financial support. When you code for a hobby or yourself, it is
difficult or even impossible to be bothered with these things, and
rightly so. Without compensation, there's often little scope (or time)
outside one's own projects for developers in the FOSS world. This is
unfortunate, but as I see it, true.

Question is, what can be done to change this or compete? Or should Pd
just become the thing that hobbyist programmers use, while Max takes
the stage as the "serious" tool for rapidly prototyping interactive
A/V artworks? I hope that this is not the case...

No flames meant in this mail, just compassionate thought-mulling.

~Kyle


On Dec 6, 2007 1:21 AM, Frank Barknecht <[EMAIL PROTECTED]> wrote:

> That's exactly the point: From this thread it seems that many of those
> people who would be able to implement segmented patchcords aren't
> interested in that feature. (You'd be one of the exceptions.) So until
> someone comes along who wants seg-cords in Pd and at the same time
> could write the code, the feature stays missing. That's not unusual
> wiht open source software: features, the developers need, get
> implemented faster, others maybe never.

-- 
-

 -
  - --
http://perhapsidid.wordpress.com
http://myspace.com/kyleklipowicz

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Patrice Colet]

  In reactable, objects are connected together when inlet/outlet matches 
the good kind of data, it would be possible to do it also with PureData, 
without breaking the rules.
  If a box is dragged nearly another box, the connection would happen 
when an inlet/outlet passes into the area of another inlet/outlet.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[vade]

you have to command click on OS X - it works, and on patch coords with  
only one knee too. (select the half towards the inlet).

On Dec 6, 2007, at 10:48 AM, marius schebella wrote:

> Michal Seta wrote:
>> On Dec 4, 2007 10:09 AM, marius schebella  
>> <[EMAIL PROTECTED]> wrote:
>>> a big problem in max is that there is no undo for segmented  
>>> patchcords.
>>> once segmented, you can only delete them and redraw to make them not
>>> segmented.
>>
>> That's not true.  Ctl-click on a segmented patchcord, unsegments it.
>> I found this "shortcut" by mistake once.  Caveat, it does not work on
>> all segemented patchcords.  IIRC it works if the patchcord has a
>> minimum of 2 "knees".  Or something like that (my max demo expired a
>> while ago).
>
> not on my machine with my max version :(
> 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

Re: [PD] segmented patchcords (was Re: PD & MAX)

[marius schebella]

oh! it depends WHERE you click. thanks!
marius.

vade wrote:
> you have to command click on OS X - it works, and on patch coords with 
> only one knee too. (select the half towards the inlet).
> 
> On Dec 6, 2007, at 10:48 AM, marius schebella wrote:
> 
>> Michal Seta wrote:
>>> On Dec 4, 2007 10:09 AM, marius schebella 
>>> <[EMAIL PROTECTED]> wrote:
 a big problem in max is that there is no undo for segmented patchcords.
 once segmented, you can only delete them and redraw to make them not
 segmented.
>>>
>>> That's not true.  Ctl-click on a segmented patchcord, unsegments it.
>>> I found this "shortcut" by mistake once.  Caveat, it does not work on
>>> all segemented patchcords.  IIRC it works if the patchcord has a
>>> minimum of 2 "knees".  Or something like that (my max demo expired a
>>> while ago).
>>
>> not on my machine with my max version :(
>> 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

Re: [PD] Max & Pd

[marius schebella]

marius schebella wrote:
> only iohannes and chris clepper are
> working on it

and that means thank you very much!
I am not sure how to really support the work you are doing? if you ever 
come up with a wishlist...
marius.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Max & Pd

[marius schebella]

Hi Andrew,
I use both. I am in a graduate class at brooklyn polytech, where josh 
goldberg teaches real time video interaction. it is an advanced class, 
and there are only 6 people, 3 of them are passionate ("professional"?) 
jitter users, and 2 people started using max in this program, but are 
also using other real time programs (or write their own C/Java/whatever 
code) plus me. It is not a dedicated max class, but max gets the 
greatest support.
I really tried hard to stay with Pd and do everything in GEM+... but at 
some point this year I realized that GEM is not at all that highly 
developed as max and jitter.
the most obvious and useful things are the tons of @arguments that each 
objects accepts. then, with pwindow you always have small control 
windows inside your patch. all textures can be referenced by giving a 
@name attribute. you can switch easily between matrix computation and gl 
world. you have better scripting support, plus more addons.
the problem with gem, as I mentioned already on the list, is that it 
does not have enough developers. only iohannes and chris clepper are 
working on it, and it is more maintenance, than active developing.
myself I am trying hard to get into GEM development, but it takes time 
until I know enough to be able to do that.
the limitations of GEM at the moment are:
no real multitexture support for opengl. that is a must, if you want to 
work with shader languages like glsl.
(jitter has that plus also javascript to combine the shaders, which in 
pd you have to do by patching.)
this should be easily fixed by someone with sufficiant knowledge of the 
opengl world and gem (and time and resources...). wesley, who is also on 
this list, but also developing for c74, wrote the lua objects for 
jitter, and pdlua should be able to do equivalent stuff on pd-side for 
that (I am working to get it included into pd-extended.) I could imagine 
that luagl people would rather use pd than max, because of open source.
on osx 10.5 the GEM window doesnot come to the front and does not accept 
mouseclicks.
I experienced problems with the colorspace on osx with some pix_obects.
on the other side jitter comes with a huge set of externals and 
abstractions. cv.jit is a great additional resource. but there are tons...
jitter has the more lively user community and you have more developers.

both programs lack of good vector graphics handling objects (like 
flash). this is a big lack in the open source world. a web savy open 
source replacement for flash!!!

still, my heart beats for the open source community, so I would like to 
see gem and pd do the same things (and more) than max and jitter can do. 
If you work in longtime installations you want to use linux and gem. 
opengl/gem on linux is faster than anything else (well at least faster 
than max/jitter). os x graphics drivers even limit some features of the 
gfx card for compatibility reasons...

for the next 3 years at least, gem will be behind, and if there are no 
new coders that will not change. I am not sure if this will change 
without money getting involved. the only other possibility to get people 
involved is teaching pd/gem at college level. and get student 
programmers involved. or grab some money for gem development. google 
summer of code, or grants...

above all that, there are all still the "obvious" pro/cons of max vs pd.
marius.

Andrew Brouse wrote:
> Hello Pd and Max folks,
> 
> I am doing a presentation (tomorrow!... so this request is a bit late!) on
> differences between Max and Pd as tools for music and media art.
> 
> I am interested in hearing:
> 
> 1. from people who actively use both
> 
> 2. about less-obvious advantages/disadvantages of one or the other
> 
> 3. specifically about functionality for manipulation of video, OpenGL 
> including shaders and matricial data
> 
> 4. clear, reasoned, articulate thoughts and arguments as to why one or the
> other is better or worse for one or another particular use ( why should I 
> expect anything else! ;)
> 
> This could have some impact on decisions which will be made for a project 
> which I can't talk about yet. :)
> 
> thanks for your help,
> Andrew
> 
> 
> 
> 
> ___
> 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

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Hans-Christoph Steiner]

On Dec 5, 2007, at 12:45 PM, B. Bogart wrote:

> Ah segmented patch coords again.
>
> How about a real solution to the problem of routing objects in  
> diagrams?
>  In PD this could mean a few things:
>
> 1. Best patching practise!!! Often you can choose not to overlap  
> objects
> and connections just by arranging objects as the connections force you
> to, which gives you the valuable side-effect of having the position of
> object show the flow of the patch more clearly.
>
> 2. Empirical tests have shown that curved (spline) connections between
> nodes are actually the best way to make them easier to follow, so yay
> for spline/curved connections and nay for segments! (See p193, figure
> 6.8 in "Information Visualization: Perception for Design" by Colin  
> Ware.)

This is the kind of stuff I am trying to get at.  I think that there  
is a lot that we can do with Pd to make it feel a lot more natural.   
I really want to get into how humans are wired to perceive the world,  
and try to reuse some of that existing circuitry to communicate  
aspects of Pd on a really low level, like unconscious.

For example, you don't need to think about it to know that you see  
something moving.  You can actually get substantial amount of data  
about a moving object without even being conscious that you paying  
attention to it.  There is a ton of circuitry in the brain that is  
constantly processing the input from all of the senses, and only a  
minute fraction of that information is ever brought forth to your  
conscious mind.  The key part is that you are not ignoring that data,  
but processing it in the background.  You don't need to be  
consciously listening to all sounds to hear your name being called.

I'm going to get that book from the library now, if anyone else knows  
some good materials on applying knowledge of persception to design,  
please let me know!  I haven't found many good resources.  Lots of  
ideas and attempts, but very few clear concepts or even examples.

.hc

> 3. I noticed the new inkscape has some very fancy graph drawing
> features, one of which is the ability to tell connections to
> automatically route around nodes. They are not curved, but the idea  
> of a
>  PD where connections simply avoid objects themselves has a lot of
> potential.
>
> Of course I'm not saying adding the choice is necessarily a bad thing,
> but the real question is what nurtures best practise? That remains  
> to be
> seen, but I'd be very surprised if segmented connections were it.
>
> .b.
>
> marius schebella wrote:
>> segmented patchcords can make patches less readable, but most of the
>> time they make patches more readable, and that is when you use so  
>> many
>> unsegmented cords that they hide the objects. also when you want to
>> connect an object at the bottom of the patch to an object at the top,
>> then you can lay the cord at the outside of the patch to make the
>> ~feed-back.
>> you don't want patchcords in situations where it is not clear anymore
>> which cord is going where.
>> a big problem in max is that there is no undo for segmented  
>> patchcords.
>> once segmented, you can only delete them and redraw to make them not
>> segmented. that might be one of the new features of max 5... as  
>> well as
>> the infinite number of undos. (true?)
>> 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



 


There is no way to peace, peace is the way.   -A.J. Muste



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] making an Italian Version of pdpedia

[Hans-Christoph Steiner]

Just ask! :D  I made the IT wiki, now create an account in it, and  
post your username here.  Then I can make it admin:

http://pdpedia.org/

I don't know if you have any contact with this group, but it looks  
like it would be good to get them to help too:

http://puredata.bugslab.net/
http://www.digicult.it/digimag/article.asp?id=901

.hc


On Dec 6, 2007, at 7:43 AM, Fabio Buda [mbutUbuntu] wrote:

> Hello folks,
> I'm Fabio Buda and I study Electronic Music at "Istituto Musicale V.
> Bellini" of Catania (Sicily). I'd like to create an Italian Wiki of
> pdpedia: what can I do?
>
> Thanks
>
> Fabio [mbutUbuntu] Buda
>
>
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



 


If nature has made any one thing less susceptible than all others of  
exclusive property, it is the action of the thinking power called an  
idea, which an individual may exclusively possess as long as he keeps  
it to himself; but the moment it is divulged, it forces itself into  
the possession of everyone, and the receiver cannot dispossess  
himself of it.- Thomas Jefferson



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Hans-Christoph Steiner]

Yes, definitely, I am thinking of something that combines the two,  
like a black box with blue inside.  I am going to play with that  
more.  The problem is that it's trickier to program that, hopefully  
it's not too tricky.

.hc

On Dec 6, 2007, at 10:48 AM, marius schebella wrote:

> I think some inlets take both, dsp and messages (throw~ for example).
> also, did you think about changing the look between edit and run mode?
> marius.
>
> Hans-Christoph Steiner wrote:
>> On Dec 5, 2007, at 4:46 PM, Phil Stone wrote:
>>> Martin Peach wrote:
 Hans-Christoph Steiner wrote:

> Color really makes things stand out, especially in a black and  
> white
> patch.  So my question is, what would this color fade be   
> communicating?  A
> fade would stand out even more than a solid color,  IMHO.  What  
> is that
> fade communicating and is it more important that  other  
> elements, like the
> object box, the inlets/outlets, the text in  the boxes, etc.
>

 I guess just a quick way to tell which end is which. For  
 instance the
 originating end could be redder and the terminating end could be  
 bluer (and
 outlets would be red and inlets blue). Or colour saturation  
 could decline
 along the cord. It may be more useful if a mouseover made the  
 colours
 appear, otherwise everything stays black.

 Martin

>>>
>>> I don't know what made me think of this from reading your post,  
>>> Martin,
>>> but it suddenly occurred to me that a good use for color would be  
>>> red
>>> (or orange, or yellow... ) for "hot" inputs to objects.  I'm not  
>>> sure if
>>> it could be practically implemented without modifying the object's
>>> source, though.  While for 99% of objects, it would be the left  
>>> inlet,
>>> in the exceptional cases like [timer], the visual reminder would be
>>> particularly valuable.
>> That is a nice idea, it would be good to have on the GUI Ideas  
>> wiki page:
>> http://puredata.info/dev/GuiIdeas
>> I've been playing with a color a bit in Pd-extended recently, I  
>> think a little bit of color used judiciously can definitely make  
>> things more readable.  Here are two examples of where I think it  
>> helps (check the inlets/outlets and the error box):
>> - 
>> ---
>> The audio inlets are colored and solid, the message inlets are  
>> black/white box.
>> .hc
>>>
>>> Phil Stone
>>> pkstonemusic.com


 ___
 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
>> - 
>> --- If you are not part of the solution, you are part of the  
>> problem.
>> - 
>> ---
>> ___
>> PD-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list



 


If you are not part of the solution, you are part of the problem.



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[marius schebella]

Michal Seta wrote:
> On Dec 4, 2007 10:09 AM, marius schebella <[EMAIL PROTECTED]> wrote:
>> a big problem in max is that there is no undo for segmented patchcords.
>> once segmented, you can only delete them and redraw to make them not
>> segmented.
> 
> That's not true.  Ctl-click on a segmented patchcord, unsegments it.
> I found this "shortcut" by mistake once.  Caveat, it does not work on
> all segemented patchcords.  IIRC it works if the patchcord has a
> minimum of 2 "knees".  Or something like that (my max demo expired a
> while ago).

not on my machine with my max version :(
marius.

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[marius schebella]

I think some inlets take both, dsp and messages (throw~ for example).
also, did you think about changing the look between edit and run mode?
marius.

Hans-Christoph Steiner wrote:
> 
> On Dec 5, 2007, at 4:46 PM, Phil Stone wrote:
> 
>> Martin Peach wrote:
>>> Hans-Christoph Steiner wrote:
>>>
 Color really makes things stand out, especially in a black and white
 patch.  So my question is, what would this color fade be  
 communicating?  A
 fade would stand out even more than a solid color,  IMHO.  What is that
 fade communicating and is it more important that  other elements, 
 like the
 object box, the inlets/outlets, the text in  the boxes, etc.

>>>
>>> I guess just a quick way to tell which end is which. For instance the
>>> originating end could be redder and the terminating end could be 
>>> bluer (and
>>> outlets would be red and inlets blue). Or colour saturation could 
>>> decline
>>> along the cord. It may be more useful if a mouseover made the colours
>>> appear, otherwise everything stays black.
>>>
>>> Martin
>>>
>>
>> I don't know what made me think of this from reading your post, Martin,
>> but it suddenly occurred to me that a good use for color would be red
>> (or orange, or yellow... ) for "hot" inputs to objects.  I'm not sure if
>> it could be practically implemented without modifying the object's
>> source, though.  While for 99% of objects, it would be the left inlet,
>> in the exceptional cases like [timer], the visual reminder would be
>> particularly valuable.
> 
> That is a nice idea, it would be good to have on the GUI Ideas wiki page:
> 
> http://puredata.info/dev/GuiIdeas
> 
> I've been playing with a color a bit in Pd-extended recently, I think a 
> little bit of color used judiciously can definitely make things more 
> readable.  Here are two examples of where I think it helps (check the 
> inlets/outlets and the error box):
> 
> 
> 
> 
> 
> 
> The audio inlets are colored and solid, the message inlets are 
> black/white box.
> 
> .hc
> 
>>
>> Phil Stone
>> pkstonemusic.com
>>>
>>>
>>> ___
>>> 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
> 
> 
> 
>  
> 
> 
> If you are not part of the solution, you are part of the problem.
> 
> 
> 
> 
> 
> ___
> 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

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Hans-Christoph Steiner]

On Dec 6, 2007, at 2:21 AM, Frank Barknecht wrote:

> Hallo,
> Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
>
>> On Tue, 4 Dec 2007, Chris McCormick wrote:
>>
>>> I think the key point to take from the whole discussion is that  
>>> Max/MSP
>>> users have a choice, whilst under Pd we have no choice. It's all  
>>> very
>>> well justifying how great it is to not have patch chords, but the  
>>> lack
>>> of that feature/bug definately annoys some [potential] users and  
>>> puts
>>> them off Pd. If the people want it, why not give it to them?
>>
>> Because it's easier to write a condescending justification for the  
>> lack of
>> segmented patchcords than to write the code for segmented patchcords.
>
> That's exactly the point: From this thread it seems that many of those
> people who would be able to implement segmented patchcords aren't
> interested in that feature. (You'd be one of the exceptions.) So until
> someone comes along who wants seg-cords in Pd and at the same time
> could write the code, the feature stays missing. That's not unusual
> wiht open source software: features, the developers need, get
> implemented faster, others maybe never.

But don't forget, anyone can become a developer, if they want! :D

.hc

 


Using ReBirth is like trying to play an 808 with a long stick.- 
David Zicarelli



___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] oscSend, pd argument types

[Martin Peach]

Damian Stewart wrote:
> hey,
>
> i'm trying to use oscSend to send some numeric data to another application.
>
> basically i've got a float between 0 and 1. the receiving application 
> unpacks the packet, assuming it's a float. the problem is, oscSend packs 0 
> and 1 as an int, but 0.01 - 0.999 as a float. so on the receiving 
> end i have to check if the type is an int or a float and unpack it 
> accordingly.
>
> i assume this is either caused by - the way pd passes around numbers 
> internally, or - the way oscSend interprets incoming numbers.
>
> is there any simple workaround?
>
>   
PD uses floats internally. oscSend tries makes ints out of floats which 
are equal to their integer representation
A simple workaround is to add a tiny offset to the numbers and subtract 
it on the other end.
I think it's better to use the mrpeach osc objects; you can force the 
type of the arguments of [packOSC] to be float.

Martin


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] oscSend, pd argument types

[IOhannes m zmoelnig]

Damian Stewart wrote:
> hey,
> 

> is there any simple workaround?
> 

yes, use mrpeach's [udpsend]+[packOSC] objects; they allow you use typed 
  OSC-messages and whatelse.

mfga.sdr
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] VLC rc connection

[Hans-Christoph Steiner]

I cc'ed the list since I think this is of general interest, also,  
other people can contribute there as well.

On Dec 6, 2007, at 5:00 AM, wolfgang schwarzenbrunner wrote:

> The pdpedia can actually answer this question:
>>
>> http://wiki.puredata.info/en/Special:Search? 
>> search=tcpclient&fulltext=Search
>>
>> :)
>>
>> .hc
> sorry...!
>
> found it... (well...  not using the pd wiki but google ;) )
>
> anyway i just found some sourcecodes on mr. peach´s website.
>
> i would definitely take in account to spend some time trying to  
> compile it myself. still i ve never ever compiled anything myself  
> (except from some old days when using debian... - but all of that  
> knowledge got lost somewhere between 2002 and now)
>
> so just two little question:
> - i am on osx. should i try to compile it myself or will i run into  
> s many inconveniences that it just would not work out?
> - whats a suitable compiler for osx (most common used?). will i be  
> happy with xcode?
>
> i don`t really want to bother you with such generel questions. -  
> just expect some hints. and i am not in hurry... so just write me  
> back if there is time...
>

It's included in Pd-extended as part of the 'mrpeach' library.

.hc

 


All information should be free.  - the hacker ethic





___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] oscSend, pd argument types

[Damian Stewart]

hey,

i'm trying to use oscSend to send some numeric data to another application.

basically i've got a float between 0 and 1. the receiving application 
unpacks the packet, assuming it's a float. the problem is, oscSend packs 0 
and 1 as an int, but 0.01 - 0.999 as a float. so on the receiving 
end i have to check if the type is an int or a float and unpack it accordingly.

i assume this is either caused by - the way pd passes around numbers 
internally, or - the way oscSend interprets incoming numbers.

is there any simple workaround?

-- 
damian stewart | +351 967 797 263 | [EMAIL PROTECTED]
frey | live art with machines | http://www.frey.co.nz

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] making an Italian Version of pdpedia

[Fabio Buda [mbutUbuntu]]

Hello folks,
I'm Fabio Buda and I study Electronic Music at "Istituto Musicale V.
Bellini" of Catania (Sicily). I'd like to create an Italian Wiki of
pdpedia: what can I do?

Thanks

Fabio [mbutUbuntu] Buda




___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Object to store images and movies.

[Olivier Heinry]

PDMTL has a growing number of features going into that direction too, as
well as a preset storage system. It also has very pedagogic aspects :-)



++
O.

Le jeudi 06 décembre 2007 à 12:03 +0100, Derek Holzer a écrit :
> As Thomas implicitly suggests, it is often easiest to arrange your clips 
> with names and directories which your "database" (i.e. [textfile], 
> [coll], the iem_matrix objects etc) can easily point to, such as:
> 
> /home/donal/clips/slow/
> -clip1.mov
> -clip2.mov
> -clip3.mov
> -clip4.mov
> 
> /home/donal/clips/bw/
> -clip1.mov
> -clip2.mov
> -clip3.mov
> -clip4.mov
> 
> /home/donal/clips/red/
> -clip1.mov
> -clip2.mov
> -clip3.mov
> -clip4.mov
> 
> etc etc etc
> 
> The [sprintf] object is very powerful for making filenames with 
> different directories and other variables, have a look at it!
> 
> best,
> d.
> 
> Thomas Mayer wrote:
> > Oops, forgot:
> > 
> > Thomas Mayer wrote:
> >> [read file1(
> >> |
> >> [textfile]
> >> |
> >> [read $1]
> >> |
> >> [textfile]
> >> |
> > 
> >   [open $1(
> >   |
> > 
> >> [pix_film]
> >> |
> >> [pix_texture]
> >> |
> > 
> > 
> 


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Olivier Heinry]

Le jeudi 06 décembre 2007 à 08:21 +0100, Frank Barknecht a écrit :
> Hallo,
> Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
> 
> > On Tue, 4 Dec 2007, Chris McCormick wrote:
> > 
> > >I think the key point to take from the whole discussion is that Max/MSP 
> > >users have a choice, whilst under Pd we have no choice. It's all very 
> > >well justifying how great it is to not have patch chords, but the lack 
> > >of that feature/bug definately annoys some [potential] users and puts 
> > >them off Pd. If the people want it, why not give it to them?
> > 
> > Because it's easier to write a condescending justification for the lack of 
> > segmented patchcords than to write the code for segmented patchcords.
> 
> That's exactly the point: From this thread it seems that many of those
> people who would be able to implement segmented patchcords aren't
> interested in that feature. (You'd be one of the exceptions.) So until
> someone comes along who wants seg-cords in Pd and at the same time
> could write the code, the feature stays missing. That's not unusual
> wiht open source software: features, the developers need, get
> implemented faster, others maybe never.


I am a PRO seg-cords as well although I dont miss it since [s/r
$0-dingsbums] made my life easier.

Moreover, the code has already been desired and written, "just" not been
implemented in vanilla.

Seg-cords + colored box/inlets + pdmtl +pdpedia give the opportunity to
really expand the Pd user community, not only the Pd developers side. 
It took me a while to abandon (definetely I hope, unless the European
Community cant resist the lobbying and forbids FLOSS)  both traditional
sequencers such as Logic (thanks to Pd) and OSes such as OSX (thanks to
GNU/Linux), which i did mostly under political reasons (Fight the
power :-). Still it would be great that people get _attracted_ to Pd for
both its vast possibilities AND usability (including documentation),
both low and high level programming prospects.

Cheers!
OH


signature.asc
Description: Ceci est une partie de message	numériquement signée
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Object to store images and movies.

[alejo d]

hi derek, thomas,,
not sure, i havent read the whole thread but for clips and images
lluis has some objects (i have to try but the suggested link is down
and doesnt resolve for me since few weeks... though all is in CVS)

"there is a [videogrid] object gui that do exactly this. you can
download it here
http://artefacte.org/pd/";

/a

On Dec 6, 2007 12:03 PM, Derek Holzer <[EMAIL PROTECTED]> wrote:
> As Thomas implicitly suggests, it is often easiest to arrange your clips
> with names and directories which your "database" (i.e. [textfile],
> [coll], the iem_matrix objects etc) can easily point to, such as:
>
> /home/donal/clips/slow/
> -clip1.mov
> -clip2.mov
> -clip3.mov
> -clip4.mov
>
> /home/donal/clips/bw/
> -clip1.mov
> -clip2.mov
> -clip3.mov
> -clip4.mov
>
> /home/donal/clips/red/
> -clip1.mov
> -clip2.mov
> -clip3.mov
> -clip4.mov
>
> etc etc etc
>
> The [sprintf] object is very powerful for making filenames with
> different directories and other variables, have a look at it!
>
> best,
> d.
>
> Thomas Mayer wrote:
> > Oops, forgot:
> >
> > Thomas Mayer wrote:
> >> [read file1(
> >> |
> >> [textfile]
> >> |
> >> [read $1]
> >> |
> >> [textfile]
> >> |
> >
> >   [open $1(
> >   |
> >
> >> [pix_film]
> >> |
> >> [pix_texture]
> >> |
> >
> >
>
> --
> derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
> ---Oblique Strategy # 20:
> "Be extravagant"
>
> ___
> 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

Re: [PD] Object to store images and movies.

[Derek Holzer]

As Thomas implicitly suggests, it is often easiest to arrange your clips 
with names and directories which your "database" (i.e. [textfile], 
[coll], the iem_matrix objects etc) can easily point to, such as:

/home/donal/clips/slow/
-clip1.mov
-clip2.mov
-clip3.mov
-clip4.mov

/home/donal/clips/bw/
-clip1.mov
-clip2.mov
-clip3.mov
-clip4.mov

/home/donal/clips/red/
-clip1.mov
-clip2.mov
-clip3.mov
-clip4.mov

etc etc etc

The [sprintf] object is very powerful for making filenames with 
different directories and other variables, have a look at it!

best,
d.

Thomas Mayer wrote:
> Oops, forgot:
> 
> Thomas Mayer wrote:
>> [read file1(
>> |
>> [textfile]
>> |
>> [read $1]
>> |
>> [textfile]
>> |
> 
>   [open $1(
>   |
> 
>> [pix_film]
>> |
>> [pix_texture]
>> |
> 
> 

-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 20:
"Be extravagant"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Object to store images and movies.

[Thomas Mayer]

Oops, forgot:

Thomas Mayer wrote:
> [read file1(
> |
> [textfile]
> |
> [read $1]
> |
> [textfile]
> |

  [open $1(
  |

> [pix_film]
> |
> [pix_texture]
> |


-- 
"Prisons are needed only to provide the illusion that courts and police
are effective. They're a kind of job insurance."
(Leto II. in: Frank Herbert, God Emperor of Dune)
http://thomas.dergrossebruder.org/

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] segmented patchcords (was Re: PD & MAX)

[Frank Barknecht]

Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:

> On Tue, 4 Dec 2007, Chris McCormick wrote:
> 
> >I think the key point to take from the whole discussion is that Max/MSP 
> >users have a choice, whilst under Pd we have no choice. It's all very 
> >well justifying how great it is to not have patch chords, but the lack 
> >of that feature/bug definately annoys some [potential] users and puts 
> >them off Pd. If the people want it, why not give it to them?
> 
> Because it's easier to write a condescending justification for the lack of 
> segmented patchcords than to write the code for segmented patchcords.

That's exactly the point: From this thread it seems that many of those
people who would be able to implement segmented patchcords aren't
interested in that feature. (You'd be one of the exceptions.) So until
someone comes along who wants seg-cords in Pd and at the same time
could write the code, the feature stays missing. That's not unusual
wiht open source software: features, the developers need, get
implemented faster, others maybe never.

Ciao
-- 
 Frank Barknecht _ __footils.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Object to store images and movies.

[Thomas Mayer]

Donal Carey wrote:
> Hi Derek
> 
> Thanks for the reply - to follow on from your info, can I create the 
> "database" in PD or would I have to use some other program and then read 
> from that using PD ?

One way to accomplish that would be using [textfile]s:

file no1. contains the file names of the textfiles that itself contains
the files for [pix_texture], sth like:

content of file1:

slow;
faster;
fast;

content of slow:

slow_movie1;
slow_movie2;

...

[read file1(
|
[textfile]
|
[read $1]
|
[textfile]
|
[pix_film]
|
[pix_texture]
|

...

every time, the first [textfile] receives a bang, the next line is
selected, the right outlet of [pix_film] gives a bang when the movie is
finished, use that to bang the _2nd_ textfile, so that after
slow_movie1, slow_movie2 is used. Read the help patches as well.

cu Thomas
-- 
"Prisons are needed only to provide the illusion that courts and police
are effective. They're a kind of job insurance."
(Leto II. in: Frank Herbert, God Emperor of Dune)
http://thomas.dergrossebruder.org/

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] segmented patchcords (was Re: PD & MAX)

[Nikola Jeremic]

hi lis
this is a big discussion :)
im a long term pd user, and no max user
I vote YES for the segmented patchcords.
i belive that it is not good to use them ALWAYS but i came i the situatuon
when they come in handy
and the user have a chance to choose... if you dont like them do not use
them :-), if you need them, they are there.
so i hope to see them soon in PD...

greets, n

On Dec 6, 2007 4:58 AM, Michal Seta <[EMAIL PROTECTED]> wrote:

> On Dec 4, 2007 10:09 AM, marius schebella <[EMAIL PROTECTED]>
> wrote:
> > a big problem in max is that there is no undo for segmented patchcords.
> > once segmented, you can only delete them and redraw to make them not
> > segmented.
>
> That's not true.  Ctl-click on a segmented patchcord, unsegments it.
> I found this "shortcut" by mistake once.  Caveat, it does not work on
> all segemented patchcords.  IIRC it works if the patchcord has a
> minimum of 2 "knees".  Or something like that (my max demo expired a
> while ago).
>
> ./MiS
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
www.echoplex-label.de/njeremic
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Object to store images and movies.

[IOhannes m zmoelnig]

Javier Garcia wrote:
> Wellcome Donal,
> 
> i think you are speaking about a to much complex aplication to be and 
> object (at least nowadays). 

???
an object can have arbitrary complexity.
you could make a [linux] object, that runs a virtualized full operating 
system.

however, the power of Pd is in _not_ having such blown-up object but a 
small, (more or less) orthogonal set of objects that allo you to build 
more complex objects.

in this case: there is no high-level object that provides a "media 
database"; but you can build your own in Pd (if you wanted a single 
(external) object that does all for you, you would better search (or 
create) a specialized application and stay away from Pd for that very 
purpose).
there are loads of ways to do the database, depending on your needs you 
can use file-system based storage of (media-)data, keep simple/numeric 
(meta-)data in tables, keep more complex data in textfiles, keep even 
more complex data in data-structures.


all in all, you will have to keep your media-data (films, images) on 
your harddisk instead of a specilized object, and you will be glad about 
that once you have 30 gig of data and your RAM exploded


> 
> You can construct that application with pd, but start from the begining with 
> the doc.

that is good advice


fgmasdr.
IOhannes

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list