On Tue, 8 Mar 2011, Andy Farnell wrote:
This is pure superstition and folklore, but I'm sure it had something to
do with using [knob] objects. Just a feeling in my bones.
Well, that's possibly a very good guess. Now if only someone could look at
[knob]'s code, to find out what might be wrong
On Tue, 8 Mar 2011, Lorenzo Sutton wrote:
I think I already used the cuisine metaphor here... My Italian genes
always point me to that... Along the lines of Mathieu's (?) topic in the
dataflow IRC about ready-made solutions.
« Readymade Solutions Require Readymade Problems; For Everything Els
Randomly disappearing boxes, and generally, canvas appearance that
stops
reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a
few years ago ? No idea what the problem was. Does that still happen to
anyone ?
I've used Pd 99,% of my time in windows, and don't ever remember
On Tue, 8 Mar 2011, Marco Donnarumma wrote:
I agree one can freely complain on his own blog, but, hey, fact is
you're still using a free software and the license is quite clear about
it. No warranty, if it doesn't work as you expect go on for Max. Without
bothering yourself and the others. If
I saw it quite recently.
A student showed me a patch where objects kept disappearing.
IIRC it would have been on a Mac with OSX 10.6 running
whatever was the extended release available end October 2010
I said is was probably a graphics bug and to reinstall.
AFAIK it went away.
This is pure sup
On Tue, 8 Mar 2011, João Pais wrote:
Randomly disappearing boxes, and generally, canvas appearance that stops
reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a
few years ago ? No idea what the problem was. Does that still happen to
anyone ?
I've used Pd 99,% of my tim
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote:
On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote:
I can't picture anyone wanting to set anyone else's audio settings when
they send someone else a patch.
I guess you don't work in anything but 44100 sampling rates. I have done
projects that u
On Mon, 7 Mar 2011, Miller Puckette wrote:
On Mon, Mar 07, 2011 at 04:45:09PM -0500, Mathieu Bouchard wrote:
Is that because of the version numbers ? They always begin with a zero.
I never thought of that...
It seems to be generalised all over pd : nearly all versioning of
externals and abst
On Tue, 8 Mar 2011, IOhannes m zmoelnig wrote:
On 2011-03-08 16:46, Mathieu Bouchard wrote:
It's split over two tickets because I don't really understand the
difference between the patch tracker and the bug tracker.
btw, a "bug" issue can be changed into a "patch" issue.
Yeah, but I wouldn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-03-08 16:46, Mathieu Bouchard wrote:
> On Tue, 8 Mar 2011, Matt Barber wrote:
>
>> Which reminds me: there used to be a problem with [delwrite~] where it
>> would allocate its memory when the patch containing it loaded, based
>> on the sample
On Tue, 8 Mar 2011, Matt Barber wrote:
Which reminds me: there used to be a problem with [delwrite~] where it
would allocate its memory when the patch containing it loaded, based on
the sample rate active at the time, such that if you switched Pd to a
higher sample rate after the patch loaded,
On Tue, 8 Mar 2011, Lorenzo Sutton wrote:
Hans-Christoph Steiner wrote:
I guess you don't work in anything but 44100 sampling rates. I have done
projects that use 22050 and 48k, and both won't work right unless the
sampling rate is set correctly. Therefore its an essential property of the
pa
On Mar 8, 2011, at 4:43 AM, Lorenzo Sutton wrote:
Hans-Christoph Steiner wrote:
On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote:
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote:
You can definite make persistent audio interface settings. The
preferred way is to set them in your patch
You can definite make persistent audio interface settings. The
preferred way is to set them in your patch.
>>>
>>> Preferred by whom ?
>>>
>>> I can't picture anyone wanting to set anyone else's audio settings
>>> when they send someone else a patch.
>>
>> I guess you don't work in anyth
Besides the unspecified bugs and crashes, I think what's overstated in that
blog post is the brave comparison and generalization between OS and
proprietary software. Imho it's fairly non-sense, even more 'cause not
backed up by specifications or even simple ideas.
I agree one can freely complain o
Hans-Christoph Steiner wrote:
On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote:
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote:
You can definite make persistent audio interface settings. The
preferred way is to set them in your patch.
Preferred by whom ?
I can't picture anyone wantin
Hans-Christoph Steiner wrote:
On Mar 7, 2011, at 1:28 PM, Peter Kirn wrote:
Okay, I'm with others here - what is Chris on this time?
I can see three complaints:
1. Ugly UI (fine.)
2. Lack of persistence of audio interface settings.
Actually, two comments here on that -- first, of course, you
Hi,
On Mon, Mar 07, 2011 at 10:46:02PM -0500, Mathieu Bouchard wrote:
> Right. But are some soundcards and/or drivers limited to only certain
> sampling rates ?
Actually most soundcards only support a limited number of samplerates in their
hardware, everything else then requires resampling in s
chris clepper wrote:
I get asked by people if Pd is ever coming out of beta.
I think I already used the cuisine metaphor here... My Italian genes
always point me to that... Along the lines of Mathieu's (?) topic in the
dataflow IRC about ready-made solutions.
And of course it would have bee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2011-03-08 00:43, Hans-Christoph Steiner wrote:
>
> I guess you don't work in anything but 44100 sampling rates. I have
> done projects that use 22050 and 48k, and both won't work right unless
> the sampling rate is set correctly. Therefore its a
--- On Tue, 3/8/11, Mathieu Bouchard wrote:
> From: Mathieu Bouchard
> Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on
> analogindustries.com
> To: "Max"
> Cc: "PD list"
> Date: Tuesday, March 8, 2011, 4:34 AM
> On Tue, 8 Mar 2
On Mon, 7 Mar 2011, Jonathan Wilkes wrote:
For Audio API (OSS, ALSA, etc.):
You can choose the respective menu item, then set it up in the
dialog window that pops up. Click "Save all settings" to... save
all settings. Isn't that persistent audio interface settings?
D'oh, yeah, but I don't
On Tue, 8 Mar 2011, Max wrote:
just to throw in a equally unspecific report.
Yes. It's important to answer rumours using rumours.
There's a prof who told me that she couldn't teach Pd, and it was because
of its security holes. Then she also told me that Pd doesn't have any
video support. Af
--- On Tue, 3/8/11, Hans-Christoph Steiner wrote:
> From: Hans-Christoph Steiner
> Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on,
> analogindustries.com
> To: "Mathieu Bouchard"
> Cc: "Peter Kirn" , pd-list@iem.at
> Date: Tuesday,
no doubt aware that user
>> bug reports are vital to fixing problems. I think he could have done a bit
>> more to help his situation.
>>
>> On Mon, Mar 7, 2011 at 11:45 AM, pierlu wrote:
>> Hi everybody.
>>
>> I regularly read the blog @ analogindu
Randomly disappearing boxes, and generally, canvas appearance that stops
reflecting canvas content — wasn't that a big WINDOWS®-only bug in Pd a
few years ago ? No idea what the problem was. Does that still happen to
anyone ?
I've used Pd 99,% of my time in windows, and don't ever remember t
On Mar 7, 2011, at 6:19 PM, Mathieu Bouchard wrote:
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote:
You can definite make persistent audio interface settings. The
preferred way is to set them in your patch.
Preferred by whom ?
I can't picture anyone wanting to set anyone else's audio s
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote:
You can definite make persistent audio interface settings. The preferred way
is to set them in your patch.
Preferred by whom ?
I can't picture anyone wanting to set anyone else's audio settings when
they send someone else a patch.
IOhannes
--- On Mon, 3/7/11, Hans-Christoph Steiner wrote:
> From: Hans-Christoph Steiner
> Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on
> analogindustries.com
> To: "Jonathan Wilkes"
> Cc: "chris clepper" , "Mathieu Bouchard"
>
On Mon, 7 Mar 2011, Hans-Christoph Steiner wrote:
On Mar 7, 2011, at 5:07 PM, Jonathan Wilkes wrote:
But Gridflow goes up to 9. So just make sure to install Gridflow with
Pd, and you should then be able to instantiate up to nine "simple" objects
without Pd randomly crashing on you:
Wait, are
On Mar 7, 2011, at 5:07 PM, Jonathan Wilkes wrote:
--- On Mon, 3/7/11, Mathieu Bouchard wrote:
From: Mathieu Bouchard
Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on
analogindustries.com
To: "chris clepper"
Cc: pd-list@iem.at
Date: Monday, March 7, 2011, 1
On Mar 7, 2011, at 1:28 PM, Peter Kirn wrote:
Okay, I'm with others here - what is Chris on this time?
I can see three complaints:
1. Ugly UI (fine.)
2. Lack of persistence of audio interface settings.
Actually, two comments here on that -- first, of course, you can set
this as a command-li
--- On Mon, 3/7/11, Mathieu Bouchard wrote:
> From: Mathieu Bouchard
> Subject: Re: [PD] Toughts on PD vs. Max stability on macintels on
> analogindustries.com
> To: "chris clepper"
> Cc: pd-list@iem.at
> Date: Monday, March 7, 2011, 10:45 PM
> On Mon, 7
I never thought of that...
cheers
M
On Mon, Mar 07, 2011 at 04:45:09PM -0500, Mathieu Bouchard wrote:
> On Mon, 7 Mar 2011, chris clepper wrote:
>
> >I get asked by people if Pd is ever coming out of beta.
>
> Is that because of the version numbers ? They always begin with a zero.
>
>
On Mon, 7 Mar 2011, chris clepper wrote:
I get asked by people if Pd is ever coming out of beta.
Is that because of the version numbers ? They always begin with a zero.
___
| Mathieu Bouchard tél: +1.514.383.3801 V
I just emailed Chris to see if he would send along crash logs and info.
Maybe some bugs will get fixed from this.
On Mon, Mar 7, 2011 at 2:50 PM, chris clepper wrote:
> It's a missed opportunity for everyone involved. Here was a developer of
> audio plugins with a lot of experience who could ha
On Mon, 7 Mar 2011, Peter Kirn wrote:
Anyway, I understand now - Chris is complaining generally about
stability, not about vst~. It's troubling, but he's not going into
specifics, so it's hard to know how to respond. I am genuinely curious
about what's causing his troubles; I suspect it isn't
I get asked by people if Pd is ever coming out of beta.
On Mon, Mar 7, 2011 at 2:47 PM, Mathieu Bouchard wrote:
> On Mon, 7 Mar 2011, Andy Farnell wrote:
>
> A "trial" version eh? Let's see how that comparison is working out in 30
>> days.
>>
>
> I've been running a trial version of pd for 8 or
It's a missed opportunity for everyone involved. Here was a developer of
audio plugins with a lot of experience who could have provided a lot of
valuable feedback, but chose not to do so. It doesn't take that much time
to fire off the crash log to the list or post something on Sourceforge, plus
h
On Mon, 7 Mar 2011, Andy Farnell wrote:
A "trial" version eh? Let's see how that comparison is working out in 30
days.
I've been running a trial version of pd for 8 or 9 years now. I'm waiting
for it to expire.
___
| Mathi
Re-posting as my previous post got scrubbed - sorry, Thunderbird is
convinced Pd-list archives are rich HTML. Doh. ;)
Anyway, I understand now - Chris is complaining generally about
stability, not about vst~. It's troubling, but he's not going into
specifics, so it's hard to know how to respon
A "trial" version eh?
Let's see how that comparison is working out in 30 days.
a.
On Mon, 7 Mar 2011 17:45:12 +0100
pierlu wrote:
> Hi everybody.
>
> I regularly read the blog @ analogindustries.com, and today an
> interesting post about pd vs max/msp sta
Okay, I'm with others here - what is Chris on this time?
I can see three complaints:
1. Ugly UI (fine.)
2. Lack of persistence of audio interface settings.
Actually, two comments here on that -- first, of course, you can set
this as a command-line argument,
:pie...@gmail.com>> wrote:
>>>
>>> Hi everybody.
>>>
>>> I regularly read the blog @ analogindustries.com
>>> <http://analogindustries.com>, and today an
>>> interesting post about pd vs max/msp stability on macintel app
industries.com
<http://analogindustries.com>, and today an
interesting post about pd vs max/msp stability on macintel appeared.
You can read about it here
http://www.analogindustries.com/blog/entry.php?blogid=1299508451902
To be honest, I always found pd on PPC macs to be fairly stable for my
.
On Mon, Mar 7, 2011 at 11:45 AM, pierlu wrote:
Hi everybody.
I regularly read the blog @ analogindustries.com, and today an
interesting post about pd vs max/msp stability on macintel appeared.
You can read about it here
http://www.analogindustries.com/blog/entry.php?blogid=1299508451902
the
software for years..well, just my opinion
2011/3/7 pierlu
> Hi everybody.
>
> I regularly read the blog @ analogindustries.com, and today an
> interesting post about pd vs max/msp stability on macintel appeared.
>
> You can read about it here
> http://www.analogindustri
ierlu wrote:
> Hi everybody.
>
> I regularly read the blog @ analogindustries.com, and today an
> interesting post about pd vs max/msp stability on macintel appeared.
>
> You can read about it here
> http://www.analogindustries.com/blog/entry.php?blogid=1299508451902
>
> To
Hi everybody.
I regularly read the blog @ analogindustries.com, and today an
interesting post about pd vs max/msp stability on macintel appeared.
You can read about it here
http://www.analogindustries.com/blog/entry.php?blogid=1299508451902
To be honest, I always found pd on PPC macs to be
András Murányi escribió:
On Wed, Apr 7, 2010 at 4:26 PM, Matteo Sisti Sette
mailto:matteosistise...@gmail.com>> wrote:
> I'd just like to add that the same happens to MIDI with DSP off on
> a rather strong machine (Opteron 148 @ 2200).
In which sense "the same happens"? Do you
2010/4/7 András Murányi :
>
> Sorry i meant that giving too much job (in zero logical time) to the GUI
> has an impact on MIDI timing.
>
> Andras
Hi,
What I noticed in a few project where I was using a heavy GUI and a
midi controller was a big delay in the midi signal transmission. I
always sol
On Wed, Apr 7, 2010 at 4:26 PM, Matteo Sisti Sette <
matteosistise...@gmail.com> wrote:
> > I'd just like to add that the same happens to MIDI with DSP off on
> > a rather strong machine (Opteron 148 @ 2200).
>
> In which sense "the same happens"? Do you mean that sending a MIDI message
> takes mo
> I'd just like to add that the same happens to MIDI with DSP off on
> a rather strong machine (Opteron 148 @ 2200).
In which sense "the same happens"? Do you mean that sending a MIDI
message takes more CPU time than it should?
--
Matteo Sisti Sette
matteosistise...@gmail.com
http://www.matteo
On Mon, Apr 5, 2010 at 8:43 PM, Matteo Sisti Sette <
matteosistise...@gmail.com> wrote:
> (this is a little OT respect to the thread)
>
> > nicely enough, pd's graphical interface and the actual process,
> > are separate threads,
>
> The communication between the engine of Pd ("Pd") and the graphi
On Wed, 3 Jan 2007, [EMAIL PROTECTED] wrote:
Le Samedi 30 Décembre 2006 23:27, Mathieu Bouchard a écrit :
But how does the type of those cords represent anything else than
limitations of the implementation?
Why should all the limitations of the implementation be hidden ?
If each limitation,
perhaps one solution is a set of objects (well documented) that
allows datatypes to easily be transmuted in ways that are clear and
easy to use for their new incarnation. Not that my vote counts, but
having clear separation between datatypes and how objects behave is a
boon. It makes for qu
Le Samedi 30 Décembre 2006 23:27, Mathieu Bouchard a écrit :
> But how does the type of those cords represent anything else than
> limitations of the implementation?
Why should all the limitations of the implementation be hidden ?
Be it under the guise of unexplainable behavior or inefficient pa
On Dec 31, 2006, at 5:09 PM, carmen wrote:
Yes, a lot of this kind of stuff is done for efficiency's sake,
like messages vs. audio rate data.
also for efficieny's sake (on the implementation side), some of the
newer graphical dataflow / patcher engines consider them one and
the same, and
On Dec 31, 2006, at 4:32 PM, Mathieu Bouchard wrote:
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote:
But how does the type of those cords represent anything else than
limitations of the implementation? How does the choice of
consider
Frank Barknecht a écrit :
Hallo,
Patco hat gesagt: // Patco wrote:
Patco a écrit :
The most deluding stuff is $0 for my concern, it's very harassing to
not being able to use it in messages.
all the other craps are quite tolerable here with last versions.
[i $0]
|
[$1(
is hara
Hallo,
Patco hat gesagt: // Patco wrote:
> Patco a écrit :
> >The most deluding stuff is $0 for my concern, it's very harassing to
> >not being able to use it in messages.
> >all the other craps are quite tolerable here with last versions.
> [i $0]
> |
> [$1(
>
> is harassing/boring too.
What a
Patco a écrit :
The most deluding stuff is $0 for my concern, it's very harassing to
not being able to use it in messages.
all the other craps are quite tolerable here with last versions.
[i $0]
|
[$1(
is harassing/boring too.
__
Hans-Christoph Steiner a écrit :
Yes, a lot of this kind of stuff is done for efficiency's sake, like
messages vs. audio rate data. Its hard to get around that. But the
strong types of symbol vs. float are an human-computer interface
question.
The most deluding stuff is $0 for my concern,
> Yes, a lot of this kind of stuff is done for efficiency's sake, like messages
> vs. audio rate data.
also for efficieny's sake (on the implementation side), some of the newer
graphical dataflow / patcher engines consider them one and the same, and solve
the rate-efficiency issue by allowing a
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote:
But how does the type of those cords represent anything else than
limitations of the implementation? How does the choice of considering those
things as distinct types, and the choice to not
On Sun, 31 Dec 2006, Hans-Christoph Steiner wrote:
On Dec 30, 2006, at 5:14 PM, Mathieu Bouchard wrote:
Have you read what I wrote to you, about "strongly typed" being vague
wording?
I think the wikipedia page does a pretty good job of describing it:
http://en.wikipedia.org/wiki/Strong_typing
T
On Dec 30, 2006, at 5:14 PM, Mathieu Bouchard wrote:
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote:
Pd is strongly typed, so floats and signal data are different
types, just like floats and symbols.
What is a type? (without just giving a list of the existing types
in pd)
What does "
On Dec 30, 2006, at 10:41 PM, David NG McCallum wrote:
On 27/12/06, Tim Blechmann <[EMAIL PROTECTED]> wrote:
> Do you mean that it would be difficult to figure out what's a
DSP object
> and what's not, in terms of figuring out what's in the DSP chain?
from the user point of view, i think,
On Dec 30, 2006, at 5:27 PM, Mathieu Bouchard wrote:
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote:
Much more importantly, the thick coords represent that a different
data type is passing thru the coords. It's not really an issue of
representing the implementation, instead it's repres
On Sat, 30 Dec 2006, David NG McCallum wrote:
If we're to think about the metaphor of dataflow languages, which is
essentially modelled after electronics and circuits (and I'm thinking
about analogue circuits, although I'm sure a similar argument could be
made for digital), then there should b
On 27/12/06, Tim Blechmann <[EMAIL PROTECTED]> wrote:
> Do you mean that it would be difficult to figure out what's a DSP object
> and what's not, in terms of figuring out what's in the DSP chain?
from the user point of view, i think, it's a good idea, to have a
specific separation between dsp
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote:
Much more importantly, the thick coords represent that a different data
type is passing thru the coords. It's not really an issue of
representing the implementation, instead it's representing that those
two types of coords can not be intermix
On Thu, 28 Dec 2006, Hans-Christoph Steiner wrote:
Pd is strongly typed, so floats and signal data are different types, just
like floats and symbols.
What is a type? (without just giving a list of the existing types in pd)
What does "strongly typed" mean?
Have you read what I wrote to you, ab
On Dec 27, 2006, at 12:01 PM, Mathieu Bouchard wrote:
I have some newbie questions here...
why is it that [*] is only for floats, whereas if you want to
multiply two signals one has to use [*~] ?
Pd is strongly typed, so floats and signal data are different types,
just like floats and s
On Dec 27, 2006, at 4:46 PM, Mathieu Bouchard wrote:
On Wed, 27 Dec 2006, Tim Blechmann wrote:
Matju wrote:
why is it that [*] is only for floats, whereas if you want to
multiply two
signals one has to use [*~] ?
why do patch cords have different width?
Because Miller added that in 0.35
--- Tim Blechmann <[EMAIL PROTECTED]> schrieb:
> > > and why is expr~ so slow?
> >
> > I don't know, this might deserve a look (or a
> rewrite).
>
> sample-wise dsp processing is usually way slower
> than block-wise. iirc,
> i read something about a factor 2 ...
afaik, [expr~] does non-recursi
> >> If there was no DSP chain, or if the chain included all of the non-DSP,
> >> we might delay such determination until later... (but should we?)
> > if there was no dsp chain, it would be easier to utilize several audio
> > threads (see jackdmp) ... caching would definitely be worse, though ..
> > why is there no |!/~| object like in max/msp?
>
> I don't know. Where's the [swap] that can support signals? ;)
well, a |swap| object itself is not a really good solution without an
optimizing compiler for the dsp chain ...
> > and why is expr~ so slow?
>
> I don't know, this might deserve
On Wed, 27 Dec 2006, Tim Blechmann wrote:
from the user point of view, i think, it's a good idea, to have a
specific separation between dsp and messaging, because both work with
very different concepts.
But of the difference between dsp and messaging, which ones of the very
differences of th
On Wed, 27 Dec 2006, Tim Blechmann wrote:
Matju wrote:
why is it that [*] is only for floats, whereas if you want to multiply two
signals one has to use [*~] ?
why do patch cords have different width?
Because Miller added that in 0.35 or 0.36 or some other release. But more
deeply: because i
On Wed, 2006-12-27 at 15:40 -0500, Mathieu Bouchard wrote:
> On Wed, 27 Dec 2006, Tim Blechmann wrote:
>
> > well, does polymorphism improve the expressive power in terms of
> > determination between messaging and dsp?
>
> I can't answer because I can't guess what you mean by "determination"
> h
On Wed, 27 Dec 2006, Charles Henry wrote:
What about efficiency? There may be certain advantages to defining
the data types, and constraining _inlets_ and atom types during
editing, rather than at run time. (that's just a guess)
Yes, it's an easy way to get such efficiency, and for example,
On Wed, 27 Dec 2006, Tim Blechmann wrote:
well, does polymorphism improve the expressive power in terms of
determination between messaging and dsp?
I can't answer because I can't guess what you mean by "determination"
here.
Do you mean that it would be difficult to figure out what's a DSP o
On Wed, 27 Dec 2006, carmen wrote:
Matju wrote:
why is it that [*] is only for floats, whereas if you want to multiply
two signals one has to use [*~] ? And then why is it that [*~] can
multiply a signal by a float, but [*] can't do that?
because according to Pd rules its not OK to confuse the
On Wed, 2006-12-27 at 13:43 -0500, Mathieu Bouchard wrote:
> On Wed, 27 Dec 2006, Georg Holzmann wrote:
>
> > Hm ... what do you want to say ? You want polymorphism ?
>
> I say what I say. I'm asking, would we prefer polymorphism in this
> particular circumstance, and why or why not.
>
> (Of co
What about efficiency? There may be certain advantages to defining
the data types, and constraining _inlets_ and atom types during
editing, rather than at run time. (that's just a guess)
> Hm ... what do you want to say ? You want polymorphism ?
I say what I say. I'm asking, would we prefer
On Wed, 27 Dec 2006, Georg Holzmann wrote:
Hm ... what do you want to say ? You want polymorphism ?
I say what I say. I'm asking, would we prefer polymorphism in this
particular circumstance, and why or why not.
(Of course I want polymorphism, but I don't want to push that into the
questio
> I have some newbie questions here...
>
> why is it that [*] is only for floats, whereas if you want to multiply two
> signals one has to use [*~] ?
> And then why is it that [*~] can multiply a signal by a float, but [*] can't
> do that?
because according to Pd rules its not OK to confuse the
Hallo!
Hm ... what do you want to say ?
You want polymorphism ?
LG
Georg
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
some follow-ups:
> why is it that [*] is only for floats, whereas if you want to multiply two
> signals one has to use [*~] ?
why do patch cords have different width?
> And then why is it that [*~] can multiply a signal by a float, but [*]
> can't do that?
why can |*~| multiply two signals, b
Haha at first I didn't see who posted this and thought, 'what a newb...'
Now I'm thinking that some philosophic sparring of Pd fundamentals is about
to begin. I'll make some popcorn and watch this one from the sidelines...
~Kyle
On 12/27/06, Mathieu Bouchard <[EMAIL PROTECTED]> wrote:
I ha
I have some newbie questions here...
why is it that [*] is only for floats, whereas if you want to multiply two
signals one has to use [*~] ?
And then why is it that [*~] can multiply a signal by a float, but [*]
can't do that?
And then why is it that [*~] can't multiply a float by a signa
92 matches
Mail list logo
