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
Hallo,
Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
> >It's likely because of the nice symmetry in the following common idiom
> >to get inter-onset intervals:
> >[t b b]
> >| |
> >[timer]
> >[timer] (and its relatives to some extent) is an object that is used
> >in a hot-to-cold fas
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 t
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 syst
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
On Jul 22, 2007, at 10:51 PM, Mathieu Bouchard wrote:
> 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 f
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 quest
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
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 c
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 t
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 essentially
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 no-longer-extan
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
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 "p
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 give
On Sun, 22 Jul 2007, Miller Puckette wrote:
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 "un
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
ma
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
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
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. Bu
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 the
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 usefulnes
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 miss
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
>
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 IMO
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 patc
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 w
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 h
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 i
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 la
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 nothing
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 ca
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 compatibil
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 c
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 responsibilit
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
ofte
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
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
http://artengine.ca/desire
38 matches
Mail list logo