On 23 Jul 2007, at 7:03 AM, Thomas Grill wrote:
The question for me is rather why desiredata announcements are posted
into the PD-list given that the codebase has moved away in a way that
makes it impossible to transfer most of the features.
Although I find DD an interesting project, it's
On Tue, 24 Jul 2007, Chris McCormick wrote:
So why don't more people do that? Rewrite the code the way [they think]
Miller wants instead of forking their own incompatible version of Pd?
It's a matter of paradigmatic divergences on how to back up perceived risk
with a self-coherent belief
On Mon, 23 Jul 2007, Frank Barknecht wrote:
Hm, but mostly there is, at least kind of: The hot left-most inlet
corresponds to the right-to-left triggering of many objects.
Yeah, but I was mostly commenting on internal structure of pd. sending to
the left inlet means the same as sending to
On Sun, 22 Jul 2007, Frank Barknecht wrote:
Maybe the Max/MSP reference manual, page 656? Quoting:
[...]
type of number, converting the input items as necessary). If no
argument is typed in, unpack will have two int outlets. Symbol
arguments allow symbols to pass through, and change numbers
On Sun, 22 Jul 2007, Frank Barknecht wrote:
I think, the usefulness, type-checking can have, is obvious, otherwise
we wouldn't have C. Of course, sometimes it's a pain, otherwise we
wouldn't have other languages.
I don't think that the choice of C vs other languages is just a matter of
type
On Sun, 22 Jul 2007, Miller Puckette wrote:
But to return to the original question, if my 'improvement' of
pack destroys the nice symmetry of pack and unpack arguments, this
certainly calls the design of unlack into question, since the only
reason its arguments are as they are is that they were
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sun, 22 Jul 2007, Miller Puckette wrote:
But to return to the original question, if my 'improvement' of
pack destroys the nice symmetry of pack and unpack arguments, this
certainly calls the design of unlack into question,
On Sun, 01 Jul 2007, Mathieu Bouchard wrote:
On Sat, 30 Jun 2007, Chris McCormick wrote:
On Sat, Jun 30, 2007 at 01:29:40PM -0400, Mathieu Bouchard wrote:
Anyway, seriously, if you wanted [unpost] as an external
for Miller's pd, you can't, because Miller rejected the
sys_printhook patch in
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
[unpack] does not have default values. If you unpack a list of length 2
using [unpack 0 0 0], the last outlet won't be used. The zero is never
used as a float. So, if one believes that the type declarations only have
to do with
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 21 Jul 2007, Frank Barknecht wrote:
It's not in my responsibility to decide, if and where people may rely
on the ouput of [unpack] and how they use it, but as I see it, [unpack
0 0] is of contract between the patch
Actually a thought occured to me: If the arguments of [unpack] should
not also specify their types, why do we have these arguments at all?
As I see it, then they would only be there to specify the number of
outlets. However using the argument count to specify the outlet count
is really awkward
Hallo,
Stephen Sinclair hat gesagt: // Stephen Sinclair wrote:
I know what you're saying, and I just had to reply: I would not be surprised
if the reason it was chosen to use the argument count was simply to ensure
that the graphical box was large enough to support the number of specified
On Sat, 21 Jul 2007, Frank Barknecht wrote:
I was hoping that compatibilty as a goal would be a two-way
compatibility: Patches, that were developed on DD would also be
running on MSP-Pd, minus some features like faster graphics or special
objects like [tracecall] (which would only be like a
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
I just find the disappearing or changing meaning of 0 confusing.
What have you ever used that meaning for?
Well, for making sure, that unpack will give a number at that outlet
or nothing there at all.
I think, the usefulness,
I'm now quite confused about the purpose and direction of DesireData.
When Chun made his presentation at FAVE last year I was very excited.
The idea of forking the pd-gui to make a much improved interface that
could be used with Pd seemed wonderful, sensible, and needed. Several
people asked
On Sun, 22 Jul 2007, Frank Barknecht wrote:
Actually a thought occured to me: If the arguments of [unpack] should
not also specify their types, why do we have these arguments at all?
[...]
So instead of [unpack 0 0 0] an [unpack 3] would create an unpack with
3 outlets for any kind of atom.
On Mon, 23 Jul 2007, Andy Farnell wrote:
Will I still be able to install the DesireData interface and use
it with Pd?
You can't use that user interface with Miller's pd because Miller's pd
does not offer the functionality required so that this user interface can
be implemented.
I've never
It's lame, but the idea behind the original design of pack/unpack
was to have the argument lists look the same. So, to send a variety
of (known-type) data down a send/receive channel or whatnot, one could
use pack tea for 2 and a corresponding unpack tea for 2.
Of course, that in the unpack
Am 23.07.2007 um 09:54 schrieb Andy Farnell:
Why are these great new objects like [tracecall] that Mathieu is
building not being added to Pd?
The question for me is rather why desiredata announcements are posted
into the PD-list given that the codebase has moved away in a way that
makes
On 7/22/07, Thomas Grill [EMAIL PROTECTED] wrote:
Am 23.07.2007 um 09:54 schrieb Andy Farnell:
Why are these great new objects like [tracecall] that Mathieu is
building not being added to Pd?
The question for me is rather why desiredata announcements are posted
into the PD-list given
Sure enough... It does not work in Pd. I checked and it still worked in
Max/FTS vintage 1993, so it's Pd at fault :)
M
On Sun, Jul 22, 2007 at 05:12:31PM -0400, Mathieu Bouchard wrote:
On Sun, 22 Jul 2007, Miller Puckette wrote:
It's lame, but the idea behind the original design of
On Sun, 22 Jul 2007, Miller Puckette wrote:
On Sun, Jul 22, 2007 at 05:12:31PM -0400, Mathieu Bouchard wrote:
There's no way to use tea and for as being default values in that
context.
Sure enough... It does not work in Pd. I checked and it still worked in
Max/FTS vintage 1993, so it's Pd at
But to return to the original question, if my 'improvement' of
pack destroys the nice symmetry of pack and unpack arguments, this
certainly calls the design of unlack into question, since the only
reason its arguments are as they are is that they were designed so
in the context of a
On Sun, 22 Jul 2007, Thomas Grill wrote:
The question for me is rather why desiredata announcements are posted
into the PD-list given that the codebase has moved away in a way that
makes it impossible to transfer most of the features. Although I find DD
an interesting project, it's
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/desiredata/gallery/unpack-mixed.png
Oh, that last one is tricky IMO. Even when you obviously don't care
about patch compatibility to other Pds anymore, making [unpack 0 0 0]
behave as you suggest may break even
In what case do you rely on using [unpack 0 0 0] except for throwing an
error when it receives a symbol? As it was previously suggested on this
list, why use anything else than [t a] or [t b]? I think Mathieu's end of
type restrictions is a great idea. For example, if you use Max/Msp every so
Hallo,
Thomas O Fredericks hat gesagt: // Thomas O Fredericks wrote:
In what case do you rely on using [unpack 0 0 0] except for throwing an
error when it receives a symbol? As it was previously suggested on this
list, why use anything else than [t a] or [t b]?
It's not in my responsibility
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/desiredata/gallery/unpack-mixed.png
Oh, that last one is tricky IMO. Even when you obviously don't care
about patch compatibility to other Pds anymore,
Well, I obviously
On Sat, 21 Jul 2007, Mathieu Bouchard wrote:
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/desiredata/gallery/unpack-mixed.png
Oh, that last one is tricky IMO. Even when you obviously don't care
about patch
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/desiredata/gallery/unpack-mixed.png
Oh, that last one is tricky IMO. Even when you obviously don't care
On Sat, 21 Jul 2007, Frank Barknecht wrote:
It's not in my responsibility to decide, if and where people may rely
on the ouput of [unpack] and how they use it, but as I see it, [unpack
0 0] is of contract between the patch author and Pd, which states,
that this construct will always give
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 21 Jul 2007, Mathieu Bouchard wrote:
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
http://artengine.ca/desiredata/gallery/unpack-mixed.png
Oh, that last one is
On Sat, 21 Jul 2007, Frank Barknecht wrote:
Ok, sorry for starting a mail thread on pd-announce
And I'm guilty for carrying on.
Well, the first post was intended as an announcement, and then immediately
any people who reply are supposed to figure out that they have to reply to
pd-list, so
On Sat, 21 Jul 2007, Thomas O Fredericks wrote:
In what case do you rely on using [unpack 0 0 0] except for throwing an
error when it receives a symbol? As it was previously suggested on this
list, why use anything else than [t a] or [t b]?
Actually, there is one single use for [t f], which
why would [route] and [symbol] be restricted to processing either all floats or
all symbols?
Why would [unpack] care whether list elements are float vs symbol vs pointer?
Well, actually, they don't anymore:
http://artengine.ca/desiredata/gallery/route-mixed.png
35 matches
Mail list logo
