Re: [PD] [pd] tables as patch storage

2012-03-27 Thread Mathieu Bouchard

Le 2012-03-27 à 12:50:00, Frank Barknecht a écrit :

On Mon, Mar 26, 2012 at 12:20:51PM +0200, Charles Goyard wrote:

Billy Stiltner wrote:

why havent i seen more usage of tables as patch storage?

Maybe because you can only store numbers, not strings.
A textfile seems more versatile.
Or a message box. Miller's help-files are crammed full with message 
boxes used as patch storage. Patch-level storga it nice for toplevel 
patches, but often not really useful in abstractions, when each 
abstraction instance needs a different state, although they all share 
the same patch file.


[textfile] fakes being a filehandle or linked-list in the way it has a 
sequential interface instead of a random-access interface, even though 
it's really stored in RAM as a binbuf.


arrays ([table]) don't have that limitation, but have other limitations. 
This creates unnecessary decisions in Pd, as people have to pick between 
free-form anythings that have to be iterated through, or direct access to 
items that have to be floats, and they can't have both advantages at once.


(Of course, there are externals, but they're not the kind of thing used by 
the kind of people who come up with list-abs.)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [pd] tables as patch storage

2012-03-27 Thread Mathieu Bouchard

Le 2012-03-27 à 08:04:00, Jonathan Wilkes a écrit :

Anythings aren't really free-form, either.  float my boat isn't a valid message in 
Pd.


I mean as free-form as storable Anythings can be. I not talking about 
atoms that are not storable, nor about non-atoms, pink elephants and 
winged pigs.


But even if you're reading a Pd file with [textfile]-- which as far as I 
know doesn't ever start with the word float--


selector float can always be implied, so it needs not be written. This is 
because of what binbuf_eval does.


(Of course, there are externals, but they're not the kind of thing used by 
the kind of people who come up with list-abs.)


I don't know what that means.  What does that mean?


list-abs was designed to only use pd's builtins, no externs, which makes 
it more like academic exercises of proving that anything can be done with 
a Turing tape machine, rather than being designed in a pragmatic way. 
There's not enough basic functionality in the language, to be able to make 
abstractions that are both simple enough and fast enough.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [pd] tables as patch storage

2012-03-27 Thread Mathieu Bouchard

Le 2012-03-27 à 17:37:00, Frank Barknecht a écrit :


On Tue, Mar 27, 2012 at 08:04:37AM -0700, Jonathan Wilkes wrote:

From: Mathieu Bouchard ma...@artengine.ca
(Of course, there are externals, but they're not the kind of thing used by
the kind of people who come up with list-abs.)


I don't know what that means.  What does that mean?


Matju is teasing me as maintainer of list-abs as a vanilla-based library,
deliberatly jumping to the wrong conclusion I would despise externals.
But I ignored the remark. Or actually now I didn't.


Well, by calling it « teasing » you're avoiding the point of my remark, 
which is essentially ignoring it. I think that you're deliberately jumping 
to the wrong conclusions about my mail, too.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] ANN: pd-l2ork v.20120304 and new disis_wiimote external now available

2012-03-27 Thread Mathieu Bouchard

Le 2012-03-06 à 00:42:00, Ivica Ico Bukvic a écrit :

Font based zooming simply changes font sizes and repositions all objects 
to be still in the same relation to each other. True zooming (ala 
desiredata), while desireable (no pun intended)


Well, in desiredata, puns were intended. The name was made from
desiderata, a latin word to allude to todo-lists and wish-lists.


is at this point IMO too much work for too little gain.


Curiously, I would have said exactly that about your fontsize thing. I 
would say that true zooming is the only way to go, and anything else 
distracts by creating bigger complications.


we really need 2 instances. One that is based essentially off of libpd 
and another that is a robust editor with none of the convoluted client 
server model between the editor and the engine itself that has made 
improving on the code so cumbersome…


You want to replace the current client-server model by what exactly ? Most 
likely another kind of client-server model ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] exit (was: list-abs and externals)

2012-03-27 Thread Mathieu Bouchard

Le 2012-03-27 à 17:45:00, Frank Barknecht a écrit :


Actually I consider list-abs to be very pragmatic *because* it only uses
builtins.


I just mean that Pd's builtins are too deficient to make your approach 
worth it. Miller has another fifteen years to spare to figure out what 
will be the five next [list] builtins.


But lists in pd aren't as inefficient as pd-list.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] for any other questions about GridFlow

2012-03-27 Thread Mathieu Bouchard


For any questions about GridFlow and related work, please write on 
gridflow-...@artengine.ca instead of pd-list.


  http://lists.artengine.ca/cgi-bin/mailman/listinfo/gridflow-dev

This is my last post (apart from pd-announce posts).

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] issue with RGB colors in GUI (toggle,bang,...)

2012-03-22 Thread Mathieu Bouchard

Le 2012-03-23 à 04:09:00, Angakok Thoth a écrit :


For example, this shade of red:
Red=192. Green=0, Blue=0
- (192*65536) - (0 * 256) - (0) = -12582912

If I make a messagebox |color -12582912[ and send it to the togglebox, i 
get bright blue. what am I doing wrong? for most shades of colours it 
seems to be working OK, but not for this one and not for some others.


You're supposed to also subtract 1 to the whole thing.

I don't know, but also the fact, the PD rewrites my messagebox to |color 
-1.25829e+007[ after save, seems suspicious to me. Is PD rounding the 
numbers in messageboxes? (the new form seems to be missing few digits)


Yes, it is rounding numbers and this destroy part of the precision that 
the internal float format has. For this reason, I recompute those numbers 
everytime I use them, but there's another reason as well : separate r,g,b 
numbers is easier to understand when reading and modifying patches.


To convert values, I use the [#to_iem] abstraction :
  http://gridflow.ca/help/%23to_iem-help.html

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [PD-dev] Filter design for iPhone

2012-03-21 Thread Mathieu Bouchard

Le 2012-03-22 à 00:39:00, Ed Kelly a écrit :

I'm anxious to know what limit is reached in the coefficients of the 
filter that causes the undefined result (NaN).


I haven't seen the code, but I just want to make you notice that adding 
together -Infinity and +Infinity results in a NaN ; so does subtracting 
two infinities of the same sign.


So, the NaN might happen when two expressions that are supposed to 
partially cancel each other, happen to both overflow, in different 
directions.


There are various possible causes for NaN, but with formulas that only 
involve +, - and *, the possibilities are a lot more limited.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] New puredata.info styled online now!!

2012-03-21 Thread Mathieu Bouchard

Le 2012-03-21 à 22:16:00, Roman Haefeli a écrit :

Though late, I still want to say that the new look is fresh. I like it. 
Nice Work!


In the left bar, the text « Modifications récentes » overlaps itself, 
suggesting a vertical spacing that is negative.


That is with FireFox 11.0 on Ubuntu 11.10.

This is the only rendering problem I see, so far, and it's only about that 
piece of text.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] alternative for quicktime

2012-03-17 Thread Mathieu Bouchard

Le 2012-03-17 à 14:41:00, Patrice Colet a écrit :

is it possible to use another library than quicktme, something rather 
open-source, in gem and griflow, and other externals like this?

I was thinking about gmerlin for example.


last year's GridFlow 9.13 binaries for OSX, link with both QuickTime and 
libquicktime. The latter is completely different code by a different 
author, can do encoding, is better supported by GridFlow than QuickTime 
is, and runs in 64-bit mode too.


Though ideally, I'd be replacing it with gmerlin, a newer library by the 
same author. Last time I looked, something about installing it was a mess, 
but I don't remember what it was, and it was years ago, so it's surely 
much better now.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] store and manipulate multiple lists

2012-03-14 Thread Mathieu Bouchard

Le 2012-03-14 à 22:17:00, Andy Farnell a écrit :


[list sort]
maybe?


does not exist.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Re : store and manipulate multiple lists

2012-03-14 Thread Mathieu Bouchard

Le 2012-03-14 à 15:26:00, Benoît Fortier a écrit :

Thanks Andy. But as far as I know, [list-sort] will sort the number in a 
list, and what I really need is to sort multiple lists according to 
their first element (which are numbers)... is there a trick with 
[list-sort] that allows to do that?


No.

What does the job is http://gridflow.ca/help/%23grade-help.html

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Anonymity.

2012-03-12 Thread Mathieu Bouchard

Le 2012-03-12 à 16:17:00, i go bananas a écrit :


maybe my google works better than yours.
http://twitter.com/#!/mahatgma


Maybe you are not proving anything at all, neither with this nor the 
account on Hurleur. I already know that there is a user named mahatGma on 
Hurleur. You didn't show that either account was the same person as 
Rabintrah, and you are ignoring what I say about the possibility that they 
are two different people (though they have this unlikely name in common).


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] call for [comport] testing!

2012-03-12 Thread Mathieu Bouchard

Le 2012-03-11 à 15:35:00, Hans-Christoph Steiner a écrit :


There is already buffering happening,


But there wasn't enough of it, obviously, because I modified an existing 
external that I'm not maintainer for, just to have a large enough buffer. 
I don't remember what was the original size, but it sucked.


my guess is at the OS level, since the bytes are read in bursts, no 
matter how fast the polling it for read or write.


At 38400 bps with 10 bits/byte, it's 3840 bytes per second. If they are 
received at full speed, they are equally spaced in time every 0.2604 ms. 
This is a time resolution that I suppose the kernel isn't especially good 
with. Back in the early days of multitasking, modem constructors even had 
to upgrade all the UART chips because OSes were not able to keep up (and 
because it was a pure waste of CPU in 99,99 % of the cases). That's when 
the buffer was upgraded from 1 byte to 16 bytes. That was precisely when 
38400 bps became a common serial rate, because 14400 bps modems all used 
MNP5 and/or v.42bis compression, and they needed to fake a fixed-rate COM 
port.


Have you tried adjusting the size of the system buffer for serial?  Is 
that even an option?


I don't recall. If there was an option for it, then it surely was 
unsufficient for what I was doing, which was to send elaborate vector 
graphics to a plotter.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] tooltips in pd-extended 0.43

2012-03-12 Thread Mathieu Bouchard

Le 2012-03-06 à 21:04:00, Ivica Ico Bukvic a écrit :

I agree, except I don't want to push this notion to the point where 
unpredictable nature of tcl/tk's canvas implementation entirely hampers 
or limits tool's productivity and provides a half-baked feature.


I found Tk to be quite predictable...

E.g. it's impossible to highlight nlets or show tooltips when trying to 
patch a cord because tcl/tk's canvas keeps current tag on the object 
that was last clicked on,


... but then I never tried using a tag named current. Here's a relevant 
piece of DesireData :


def Canvas identify_target {x y f} {
set c [$self widget]
set cx [expr $x*$@zoom]
set cy [expr $y*$@zoom]
set stack [$c find overlapping [expr $cx-2] [expr $cy-2] [expr $cx+2] 
[expr $cy+2]]
# reversing the stack is necessary for some things
# not reversing the stack is also necessary for some other things
# we have to figure out something.
set stack [lreverse $stack]
set target 
foreach tag $stack {set target [$self target $x $y $f $tag]; if {[llength 
$target]  1} {break}}
if {[llength $target]  1} {return $target} {return [list nothing]}
}

def Canvas target {x y f tag} is a much longer method, which looks at tags 
of a canvas-item to figure out where it comes from.


and yet arguably this is where a new user needs tooltips the most. 
Selection of nlets and their detection is finicky at best, is very 
unforgiving (you really need to nail that pixel on the screen to get 
it), and the list goes on.


In that code, I detect using a square of 5x5 pixels in size, where $cx $cy 
is the centre of it. This allows fuzzier detection. This is not 
necessarily the best solution, but that's what we came up with.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] High end, low end (was : some other topic)

2012-03-12 Thread Mathieu Bouchard

Le 2012-03-13 à 02:09:00, András Murányi a écrit :

Hey, I was not quoting you. I was basically replying to Matju's mail 
which was basically replying to mine, in which I was trying to explain 
my idea about the importance of Pd staying accessible for amateurs, and 
one of the expressions I used the describe the amateurs was low-end. 
Sorry if I made any confusion, by the time we arrived to low-end and 
high-end I was not having your previous posting on my mind any more.


To me, the use of expressions low-end and high-end was clearly something 
idiosyncratic, expressions that aren't used in the same way outside of 
this conversation, just like one would invent new words in a casual 
manner. I don't see them as corresponding to low art and high art.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] mrpeach routeOSC behaves differently then its previous release?

2012-03-12 Thread Mathieu Bouchard

Le 2012-03-12 à 18:36:00, Hans-Christoph Steiner a écrit :

I personally think it would be great to get rid of the separation 
between lists and non-list messages (i.e. lists of atoms that start with 
a symbol other than list).  But that's a big project that will break 
backwards compatibility.


This sounds like something that will create more problems than it will 
solve.


I mean, it's possible to be both part of the problem and of the solution. 
It happens when the solution is the problem.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] mrpeach routeOSC behaves differently then its previous release?

2012-03-12 Thread Mathieu Bouchard

Le 2012-03-12 à 22:30:00, Hans-Christoph Steiner a écrit :

Donno.  That particular rule has always felt arbitrary to me.  I don't 
think I've ever run into a case where there was an empty list being used 
as a bang.


Currently, [t a] turns every bang into an empty list, but whenever you try 
to print an empty list, [print] says «bang».


If you wish to see the true selector of every message, to see where pd is 
currently producing empty-lists in unsuspected areas, use [gf/selector].


http://gridflow.ca/help/gf/selector-help.html

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] Anonymity.

2012-03-11 Thread Mathieu Bouchard

Le 2012-03-11 à 12:03:00, Marco Donnarumma a écrit :

with all due respect, I feel your approach Mahatma is feeding war flames 
here. And I'm happy nobody is picking that up.


Have you considered that this user might be an anonymised version of an 
existing list member ? Or it might be a close friend of a list member.


Just the firstname MahatGma with a G doesn't look like it's a single 
person on Google Search, but searching for the full name leads you only to 
pd-list.


And it sounds a lot like a certain person who has been on pd-list for many 
years.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] call for [comport] testing!

2012-03-11 Thread Mathieu Bouchard

Le 2012-03-11 à 10:10:00, Hans-Christoph Steiner a écrit :

Sounds interesting, how would that affect latency?  Most people use 
comport for getting data from sensors, so that's important.


The fifo is an option. If you don't use it, then there's hardly any 
difference. If you use it, then I think that the data is only being sent 
at poll time, according to how much data the driver accepts. For patches 
that only receive, it makes no practical difference : just an extra 
if(n0) in a situation where n stays 0.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Anonymity.

2012-03-11 Thread Mathieu Bouchard

Le 2012-03-11 à 17:06:00, Marco Donnarumma a écrit :

Yep, I considered that too... in fact I specified in parenthesis, in the 
previous message.


Ah sorry, I didn't read the whole thread, and I didn't read much of the 
email I replied to.


I only assumed that if you wrote so long about it, then you are assuming 
that it's a real person.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Anonymity.

2012-03-11 Thread Mathieu Bouchard

Le 2012-03-11 à 10:12:00, Jonathan Wilkes a écrit :


From: Mathieu Bouchard ma...@artengine.ca
And it sounds a lot like a certain person who has been on pd-list for many 
years.

How is the true identity of the OP relevant here?


Because I doubt that this thread would have had as many posters and 
messages, if the real name had been written. New fresh names cause posters 
to have a very much different attitude. Using a fake name is a way to play 
with that change of attitude.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Some more float weirdness/fun

2012-03-11 Thread Mathieu Bouchard

Le 2012-03-10 à 16:31:00, Charles Henry a écrit :

How about an abstraction that uses = against 2xepsilon*|input|?  That 
would be a reliable automatic way to ignore single-bit rounding errors.


Don't you wish rounding errors would be at most single-bit.

But as you compose more operations together, error can accumulate and/or 
amplify.


This is why no-one uses a definition of == with a hardcoded epsilon in it, 
in any programming language that I ever heard of.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] tooltips in pd-extended 0.43

2012-03-11 Thread Mathieu Bouchard

Le 2012-03-10 à 11:13:00, Jonathan Wilkes a écrit :

I don't know, I think that canvas space is somewhat more touchy to 
manage in pd than in firefox, and I would think that it's not that much 
about full-width... the full-height seems at least as important... and 
the fact that pd patches always state their own size, while web pages 
rarely do... and pd patches more often rely on it... and it's often 
because they have no real means to do otherwise.


I have no idea what this means.  Try out the tooltips and see how they 
interact with the canvas.  I am in no way resizing the canvas nor the 
window.


I was trying to talk about both the statusbar approach and the transient 
approach at the same time, sorry.


I'll try it... eventually... but these days, all I do with pd is a bit of 
music and that still makes me too lazy to get out of ext 42.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Anonymity.

2012-03-11 Thread Mathieu Bouchard

Le 2012-03-12 à 12:11:00, i go bananas a écrit :

It's a real person.  
http://puredata.hurleur.com/recherche-1521813748.html


This returns « no hits ». It seems that this URL can't be pasted.

And http://puredata.hurleur.com/profil-1751-mahatgma refers to Aykut 
Caglayan, who has been posting to pd-list using aykut_caglayan at 
yahoo.com in the last two years including 10 days ago, and it is not the 
same address as the new mahatgma.


It seems that jumping to conclusions is a popular sport ; especially as it 
actually involves less effort than not practicing it.



so i'm sorry Mathieu, but it seems that the dislike for your guru status


It is strange that this g-word springs up in the complaints, because this 
word comes up only a few times per year on pd-list, and it's rarely ever 
about someone in particular (once in several years...).


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] tooltips in pd-extended 0.43

2012-03-10 Thread Mathieu Bouchard

Le 2012-03-06 à 15:38:00, Jonathan Wilkes a écrit :

Status bar would be like an extra widget (label I guess) running the 
full width of the window that is below the canvas, so it won't overlap 
the canvas but wouldn't leave after the tip goes away.


How do I say that... Make sure that you don't create a situation in which 
people have to add more extra room in each patch to make space for 
something that may be transient but might overlap the wrong thing, e.g. 
the thing you're trying to edit or to have tip info about.


Note that currently, patches save the window size, and not the canvas 
size. Perhaps it is time to move to saving a fudged canvas size, that is 
meant to be compatible with existing patches but is meant to compensate 
for a permanent status bar or any other additional structure.


The transient thing is harder to take into account... it is meant to both 
be used as a statusbar, and be counted as canvas space ?...


I don't know, I think that canvas space is somewhat more touchy to manage 
in pd than in firefox, and I would think that it's not that much about 
full-width... the full-height seems at least as important... and the fact 
that pd patches always state their own size, while web pages rarely do... 
and pd patches more often rely on it... and it's often because they have 
no real means to do otherwise.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] question about moses/gate/split??

2012-03-10 Thread Mathieu Bouchard

Le 2012-03-10 à 18:23:00, Pagano, Patrick a écrit :


If x can equal 1,2,3,4 and y can equal 1,2,3,4 how to send a bang when
x=1  y=1 BANG 1
x=1  y=2 BANG 2
x=2  y=1 BANG 3
x=2  y=2 BANG 4


if x3  y3 then bang y*2+x-2

[moses 3] for x

[moses 3] for y

once you have computed y*2+x-2, use [sel 1 2 3 4] to turn them into bangs.

alternately, don't use moses, use y*4+x-4, now all your combinations are 
numbered from 1 to 16, and you can use [sel 1 2 5 6] to pick the four 
you're currently interested in, and you can later pick other combinations 
by changing the sel.


Whenever you change the range of x, change the multiplier of y and the 
subtracted constant.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] call for [comport] testing!

2012-03-10 Thread Mathieu Bouchard

Le 2012-03-07 à 00:03:00, Hans-Christoph Steiner a écrit :

I just committed a fix for the race condition that happens when a serial 
port gets disconnected on GNU/Linux and Mac OS X.  Please test heavily 
on those platforms, including yanking out the USB plug and going out of 
range with a bluetooth.  It should just cleanly close the serial port 
now.


BTW, I have made a version of [comport] in 2008, to introduce an optional 
ring-buffer FIFO for outgoing data, with user-defined size, because I 
needed to upload large files by serial port. It might be a good idea to 
merge this feature into the main [comport] branch, for several reasons. 
One of them is that I'm not really distributing it anywhere.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Some more float weirdness/fun

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 08:32:00, Roman Haefeli a écrit :


But 0.1 still cannot be represented exactly by float64, can it?


It can't. It also doesn't work for any other form of binary floating 
point. It's just that float64 is a lot closer to exact than float32 can 
be, and so on.


0.1 = 1/10 = 1/(2*5) in prime factors.

This means both 2 and 5 need to be present as prime factors in the base of 
the format, to have an exact fraction for it. So, decimal floats obviously 
can, and the only other bases that allow it are multiples of 10.


for 1/44100 = 1/(2*2*3*3*5*5*7*7), the smallest base to do it exactly is 
2*3*5*7 = 210.


for 1/48000 = 1/(2*2*2*2*2*2*2*3*5*5*5), the smallest base to do it 
exactly is 2*3*5 = 30.


I'm just saying that as examples of the principle for exact fractions ; in 
practice, bases that aren't binary nor decimal are rarely ever used, and 
decimal floats are almost only used as textfile versions of binary floats 
(such as in the pd file format and most programming languages).


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Some more float weirdness/fun

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 09:39:00, Charles Henry a écrit :

Martin a écrit :

For any floatX unless X is infinity the number of floats that are not
exactly represented is always infinite.


For a floatX format where X is the number of bits, every float is exact 
and there are at most pow(2,X) floats.


You mean that there are an infinity of numbers that round to a finite 
number of floats.


There is a countably infinite number of rational numbers and a 
uncountably infinite number of irrational numbers that cannot be 
represented.


From a constructivist point of view, there's a countably infinite number 
of irrationals that can be represented at all no matter how. For a certain 
ontology useful to constructivism, it can be said that the uncountably 
many irrationals that are inexpressible also don't exist.


This leaves you with countably many rational numbers and countably many 
irrationals, that can't be represented in a finite format.



We could also debate over whether infinity is exactly represented.
When some math operation overflows (exceeds the range of floats), the
result assigned is inf.


Every float represents a range of numbers. The difference with infinities 
is that they represent half-intervals, that is, a line bounded only on one 
side.


That's not the definition of infinity either: Take the set of real 
numbers R and the ordering operation , then add an additional point 
infinity such that for any x belonging to R, x  infinity.


You should know that there are several competing definitions of infinity 
for real numbers (not considering other number systems in which this 
definition doesn't work).


There are three definitions of Real numbers (R) in common use : one 
without any infinite number, one with two infinite numbers as endpoints, 
and one with a single infinite number without a sign. There are different 
motivations for the use of each of those three sets. There's no definition 
that fits all purposes, though the one without infinite numbers at all is 
considered generally «cleaner» in the field of pure math.


So, the inf in the float definition only represents infinity defined 
relative to the finitely countable set of numbers that can be 
represented as floats


Yes, except NaN.

You'll also find out that certain definitions of infinity that applies to 
the whole set of Reals also are relative to just that set, and don't work 
as-is for all possible extensions of Reals ; for example, Complex numbers 
don't have a single coherent definition of less-than and greater-than 
anymore, because all you can do is extract features of Complex numbers and 
compare those features as Reals... thus you need more specific 
definitions (and there are more possibilities of them).



not the actual infinity as represented in your head :)


How do you know what's in people's heads ?

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Am I in time to propose the Xth Sense lib to be included in Pd-ext?

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 15:20:00, Marco Donnarumma a écrit :

wow, PdMtl is out there since ages...  I always thought why it is not 
yet included. 


Yes, and there are also much older libs than that, that aren't included 
either.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Web Netiquette Re: Making Musical Apps: a book about libpd

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 17:08:00, András Murányi a écrit :

I meant myself, for example - and everyone who doesn't do Pd fulltime, 
thus cannot really afford to learn using the more complicated 
parts/methods. So to say, the barriers to entry shall be kept low.


Nearly none of the Pd professionals use Pd «fulltime».

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Web Netiquette Re: Making Musical Apps: a book about libpd

2012-03-09 Thread Mathieu Bouchard
I meant myself, for example - and everyone who doesn't do Pd fulltime, 
thus cannot really afford to learn using the more complicated 
parts/methods. So to say, the barriers to entry shall be kept low.



Nearly none of the Pd professionals use Pd «fulltime».


Yeah. The question is, do you understand the point I was trying to make 
with my less professional English? Then I'm also interested if you agree 
with it.


I don't necessarily... « à temps plein » or « full time » means as a main 
occupation. The definition is variable, but in my country, this is 
normally assumed to mean 30 hours per week in a sustained way, especially 
50 weeks per year. Even when including all the non-patching activities 
that revolve around Pd or mostly-Pd projects, very few Pd professionals 
put that much time in Pd. Are there any at all ?


If you don't mean that, then it's probably not a matter of your skills of 
English, but rather about stating your opinion precisely enough.


But yes, I agree with what I think that you are saying. But I think that 
there is a continuüm of time investment that gradually makes the learning 
more worth the effort, and it begins at a tiny amount of part-time such as 
just a few hours per week.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] Tobacco (was: Web Netiquette (was: a book about libpd))

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 14:26:00, Py Fave a écrit :


the problem with cigarettes is being able to make your own.


The problem with cigarettes is smoking them. If it were not a problem, 
then the problem would be to grow them, because if you merely roll them, 
then you're still buying Drum tobacco and Riz Lacroix (RizLa+) paper from 
the same company as Gauloises, Gitanes and JPS, for example, which are all 
readymade, if that's the problem you have with them.


But the problem with cigarettes is smoking them. The companies selling 
them created the lifestyle and encouraged the craving. Basically everybody 
fell for that.


An association of ninety thousand smokers sues tobacco companies over 
health issues for 23 billion of $ right now. They deposited their request 
in 1999, and one should wonder why it took that long for the courts to 
accept launching the trial. In the end, the Cour Supérieure du Québec will 
start hearing them now. This makes it the largest anti-tobacco trial ever 
in Canada.


http://www.ledevoir.com/societe/justice/344619/le-megaproces-du-tabac
http://www.cyberpresse.ca/le-soleil/actualites/justice-et-faits-divers/201203/08/01-4503809-recours-collectif-des-victimes-du-tabac-le-proces-debute-13-ans-plus-tard.php

(But this seems extremely underreported in canadian english-language 
media... you may only guess why that is.)


Anyway... what you say has nothing to do with Julian's problem with 
cigarettes, and neither does what I'm saying now.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Some more float weirdness/fun

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 19:18:00, Quim Llimona a écrit :

It's well-known that floats can't be treated the same way as integers... 
but since PD is aimed at non-engineers and non-scientists I think it 
would be a good idea to implement the good comparison algorithms (i.e. 
checking against a threshold, etc) inside [==] and so, just to make 
patching easier.


Do you think it makes any sense to change the definition of [==] given the 
extent to which Pd has been used already ?


And then, [==] couldn't just try to be smart and pick a threshold for you. 
You need to explicitly tell which threshold you want it to use. Any kind 
of automatic threshold will end up being an annoyance, a nuisance or 
worse.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Tobacco (was: Web Netiquette (was: a book about libpd))

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 13:45:00, Mathieu Bouchard a écrit :

The problem with cigarettes is smoking them. If it were not a problem, 
then the problem would be to grow them, because if you merely roll them, 
then you're still buying Drum tobacco and Riz Lacroix (RizLa+) paper 
from the same company as Gauloises, Gitanes and JPS, for example, which 
are all readymade, if that's the problem you have with them.


(I blew that last sentence : I actually just mean that the same companies 
produce the readymade cigarettes and the roll-your-own cigarettes, if the 
problem is who is producing them, what's their policy, or how much of the 
market they own.)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] High end, low end (was : some other topic)

2012-03-09 Thread Mathieu Bouchard

Le 2012-03-09 à 19:58:00, András Murányi a écrit :

Then they have a certain high end, the more advanced topics within - 
e.g. dynamic patching for me, or libPd according to Julian. Now, someone 
can fear that the focus of developments could move towards the high 
end, leaving simple folks increasingly frustrated.


Many projects are driven by the high-end. It's necessary. They're also 
driven by the high-end. Many low-end features start existing because 
high-end features first allowed them to exist. If someone makes an 
easy-to-use polyphonic synth, this synth might be using dynamic-patching 
features, perhaps new ones or new ways of using the old ones. This needs 
high-end development. In projects like Pd, development has always to be 
multi-focus.


It isn't just that. Even in the case of unrelated features, high-end 
features are what keeps the high-end users around, and they're the ones 
who write externals and abstractions, both for themselves and for others. 
Low-end users don't produce nearly as much low-end abstractions and 
externals as high-end users do.


It's that the very ability to figure out what should go in a given 
abstr/extern, and what should be left out, and all the strategies of how 
to specify args, etc., those are all skills that are characteristics of 
high-end users. Every such skill moves you towards the higher-end.


At some point I had to realise that I couldn't just ask students to make 
abstractions... I mean that I couldn't just teach them the mechanics of $1 
arguments and $0-foo local variables. They still haven't thought about how 
to figure out which ideas should become abstractions and which shouldn't, 
etc. ; they'd need something of the order of « Introduction to 
programming », perhaps several semesters, but I remember that in 
university, after the 4th such course, students only began to figure out 
what could be a good library vs a bad one. So, definitely, Pd users who 
didn't go through the equivalent of those courses (or of some other 
related courses) rarely would publish a library that other people would 
want to use. So, it's important that high-end users keep on making low-end 
components.


It's also that everybody needs to use some of those « low-end 
components »... there are lots of things common to all users. And even 
though high-end users can more easily tolerate design problems and bugs 
and various difficulties, they don't necessarily like them.


I don't share, but I think I can understand that fear, and my point was 
that Pd shall keep the low end accessible and up-to-date.


Actually, I wonder which features you have in mind when you say that.

Yea, this is what we call in our wonderfully expressive Hungarian 
language szőrszálhasogatás :o)  


What I mean about that, is that for making your point, saying full-time 
isn't simply a small exaggeration. Otherwise, I don't think I'd have made 
a fuss.


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


Re: [PD] Some more float weirdness/fun

2012-03-08 Thread Mathieu Bouchard

Le 2012-03-08 à 11:47:00, Jonathan Wilkes a écrit :


From: Roman Haefeli reduz...@gmail.com
That's a good example of the implications inherent in floats. What you
call a work-around is actually the correct solution. When counting, make
sure you count with something that can precisely represented by floats,
otherwise the error will grow with each iteration. Integers up to
1.6*10^7 meet that criterion.

Is this still an issue when float precision is 64-bit?


in float32 you have 24 significant bits.
in float64 you have 53 significant bits.

This means that the limit is pushed back from 16777216 to 9007199254740992 
instead.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Making Musical Apps: a book about libpd

2012-03-08 Thread Mathieu Bouchard

Le 2012-03-08 à 18:36:00, Peter Brinkmann a écrit :

Shawn and I accidentally crossed wires here --- Shawn didn't know that I 
had already sent a message to Pd-Announce, and I didn't know that Shawn 
would be posting to Pd-list.  We will coordinate better in the future, 
and we apologize for the duplication. Sorry about the spammy aftertaste,


I don't think that there has been any real problem with the way that it's 
been announced. I mean, it's not like you put a cronjob for it, or wrote 
any kind of false representation, or advertised random unrelated products.


So, I don't think that you need to say you're sorry, nor to be sorry at 
all. Think of all the times that someone replied to a mail to both pd-list 
and pd-announce, which causes triplicata to anyone subscribed to both, and 
I don't think that anyone ever expressed an emotional response about it on 
the list !


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] tooltips in pd-extended 0.43

2012-03-06 Thread Mathieu Bouchard

Le 2012-03-06 à 14:11:00, Jonathan Wilkes a écrit :

I do, too, but every GUI toolkit and its brother hovers them to the side 
of the current mouse location.


A function for setting the current tooltip of a certain window could look 
into user settings to figure out automatically whether a certain piece of 
text is to appear in a balloon vs in a label widget in a statusbar frame 
at the bottom of the window. Users would have the choice, while GUI-Class 
developers and GUI-Plugins developers wouldn't have to even think about 
it.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] tooltips in pd-extended 0.43

2012-03-06 Thread Mathieu Bouchard

Le 2012-03-06 à 14:40:00, Jonathan Wilkes a écrit :

There are actually three possibilities-- balloon, statusbar, and window item at 
the bottom of the patch (which is the current pd-extended implementation).


I don't know what's the difference between the last two...

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] Music Notation in linux

2012-03-05 Thread Mathieu Bouchard

Le 2012-03-05 à 09:07:00, Lorenzo Sutton a écrit :

On 05/03/12 01:43, Mathieu Bouchard wrote:

Le 2012-03-03 à 22:54:00, Lorenzo Sutton a écrit :

You can create a midi output, with all the drawbacks and benefits. As far 
as I know there is no lilypond player, but to be totally honest I'm not 
sure it would make so much sense as lilypond is primarily a music 
typesetting language.


Do you also mean it doesn't make much sense to use PureData for anything 
else than audio ?
No, nor I see the logic by which you assume I mean that from the above 
statement.


Think of sentences like « It doesn't make much sense to use X as a Y 
because X is primarily a Z »...



And computers were only meant for doing math, too.

Indeed they are.
And I don't think math is anything dirty, with less dignity than other 
disciplines, or to be ashamed of.


I'm not alluding to that, I mean how computers aren't often used to 
explicitly doing math, whereas in the 1930's, the most newfangled user 
interface of the computer was a paper tape on which you'd punch 
machine-language directly, and you explicitly put numbers in and got 
numbers out, if you turned the crank for long enough.


Nowadays, numbers are still all over the interface, but they're not 
necessarily seen as numbers. This is what allows the numbers to become 
pixels and sound samples, for example.


Computers are very powerful, yet stupid, calculators. In fact in Italian 
we still use the word calcolatore to address a computer.


The word «computer» is even stupider, as it's the same root as «counter», 
french «compteur». A computer is just a counter. At least calcolatore 
implies it could do other math than just count !


And of course 'computer' itself stems from the French computer, and in 
turn from the Latin computare. [1]


I think French never had «compute(u)r», it had compte(u)r with a silent p 
written only to make it look like latin (the -er suffix is verb, the -eur 
suffix is noun). This dropping of «pu» in French is where English's 
«counter» comes from. French also has a quite rare word «comput» (without 
suffix and without corresponding verb), which might have inspired the 
English word, though it's also possible that English took it directly from 
Latin.


(But the word for «computer» in French is entirely different : in the 50's 
or 60's, «ordinateur» got coined using an metaphor of sorting things out, 
putting *order* into things.)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] ordering arrays based in similarity

2012-03-05 Thread Mathieu Bouchard

Le 2012-03-05 à 09:09:00, William Brent a écrit :

If you do end up treating each of your messages like a vector, the 
[choice] extern is good for this kind of thing.  But you have to 
implement the weighting on your own before sending anything to it.


Vector is a quite polysemic word... it's nice to note that «vector» here 
means a Hilbert space using a plain dot-product. Meaning that the concept 
doesn't have so much to do with std::vector (C++) nor java.util.Vector 
(Java).


Also one other thing to note, is that it doesn't compute the euclidean 
distance between points, which is the other easiest possible comparison.


If you have three numbers a b c that you wish to compare with x y z, the 
dot-product used in your solution is a*x+b*y+c*z, which is then divided by 
sqrt((a²+b²+c²)*(x²+y²+z²)), a scale factor that brings back the 
similarity to something between -1 and +1. In that case, +1 is the best 
match, -1 is the best backwards match (if you use negatives), and 0 is the 
most unrelated thing possible.


The euclidean distance, however, is sqrt((a-x)²+(b-y)²+(c-z)²).

The dot-product thing is like comparing angles between arrows, to find 
which arrow is in the most similar direction ; and the euclidean distance 
is like comparing distances between points, to find which is closest.


Both are extremely common and useful.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] Computers just for maths? WAS Music Notation in linux

2012-03-05 Thread Mathieu Bouchard

Le 2012-03-05 à 08:22:00, Andrew Faraday a écrit :


It's also pretty fair to say that all computers do IS maths.


I know all of that and understand those principles from beginning to end. 
But I'm not talking about that. I mean the users' activities.



They perform binary operations at a rate of thousands per second.


Wow, that really sounds exciting !

For a 1936 Zuse-1 computer with 22-bit ints and 33-bit floats running at 1 
Hz, there were already hundreds of them. Nowadays, it's impossible to get 
a damn phone that doesn't already do several billions per second.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] Music Notation in linux

2012-03-05 Thread Mathieu Bouchard

Le 2012-03-05 à 19:58:00, Lorenzo Sutton a écrit :

It can be dangerous/misleading to extract the general rule from one 
single, very specific example like this, and then re-apply it to a 
totally different domain/example.


Yes, but then, the reasoning that you stated is not what you actually 
meant. You're not trying to say that it doesn't make sense to use 
something that is primarily a typesetting system, to do midi output. It 
may be because Lilypond in particular is bad at this task in particular, 
but you already are generalising by calling it « a midi creator » and « a 
typesetting system » and that a fact about the latter in general justifies 
a statement about the former in general.


I'm not saying that I really expressed myself well in yesterday's reply... 
It was a bad way to put it.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] six sound outputs with sound blaster X-Fi Surround 5.1

2012-03-05 Thread Mathieu Bouchard

Le 2012-03-05 à 15:03:00, Charles Henry a écrit :


Sorry--I have no good news for you... and perhaps this knowledge only
adds to your injury.  The ASIC in your sound card has many, many times
the potential that it actually gets used for--up to 10,000 MIPS on a
quad-core DSP and up to 128 channels.


It's just normal that increasingly more powerful technology becomes 
generic so that it can be used in many more products so that it can sell 
more so that it can pay for its own development and cut down on the 
production costs... eventually we put supercomputers inside 
chequebook-sized boxes and call them « telephones ».


The best you can do is write a distributed-computing virus that detects 
any such ASIC and hook it on some math problem such as trying to crack 
exterrestrial prime numbers and stuff... ;)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-03-04 Thread Mathieu Bouchard

Le 2012-03-04 à 03:10:00, Billy Stiltner a écrit :

What we need is flat address space without the overhead of GDS segment 
sorcery.


What's GDS ? Is that a Windows-only thing ?

It's pretty bad to be able to delete a  list of a list of pointers to 
objects that deletes itself before it deletes itself in a polymorphic 
virtual destructor. ;)


Any language with sufficient power will have to allow the user to screw 
up. C gives you the power to decide of your own allocation duration (after 
malloc, how long before you free). But C also gives you the power to write 
your own automatic-free, or use someone else's. C++ makes it easier in 
some ways (ref-counting can become almost completely implicit).



C++ is great but it is much easier to keep up with pointers in c.


Please don't make it look like you didn't try C++ ;) In C++ you have a 
larger number of constructs you can use ; in C you have to reuse the same 
constructs in more different ways before you can get to the same solution. 
Any C++ programme could have been written using C by the means of more 
funny tricks and longer, more redundant code. The length and redundancy is 
sometimes all it takes to make bugs harder to find.


c is just like c++ without the confusion you can work yourself into a 
pointer to a function is a pointer to a function


I can't parse your sentence... sorry

and if yo look at the assembly language there aint nothing wrong with 
using struct instead of class.


In C++, struct and class are near-synonymous. All the OOP features are 
available with the struct keyword. In fact, you never need the class 
keyword, if you don't want it to appear in your source code.



it's all code an data when its running.


Even when not running, if you ask me...

the differences in the output are going to be more than likely caused by 
leaky capacitors and noisy fans or  2 coils of wire too close together.


The differences in the output between asm, C and C++ is more likely going 
to be about which categories of bugs, in which amounts, will be found 
between the chair and the keyboard.


And I'm not talking about Cimex Lectularius.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] no tilde

2012-03-04 Thread Mathieu Bouchard

Le 2012-03-04 à 18:03:00, Gerhard Lang a écrit :


and here is my first request for guiding hands:
pd-extended 0.42.5 does not take the ~.


How do you produce it in other apps ?

We use different layouts. I've used 3 or 4 different kinds of CF layouts 
and several variants of US layouts too. I've also seen FR and DE/AT 
layouts. I remember that ~ was in a tricky place on the DE/AT Apple 
layout.


There is no keyboard dysfunction otherwise on my tp410 with ubuntu 11.4 
amd64.


Huh, what's a tp410 ? But I think that what most often matters is the 
keyboard layout, not the keyboard hardware.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] WG: no tilde

2012-03-04 Thread Mathieu Bouchard

Le 2012-03-04 à 19:37:00, Ingo a écrit :


I have to press ~ twice before it gets accepted on Ubuntu. Only once
with Windows, though.


Several layouts have a «dead» ~ key, used for writing ãẽĩõũ. Pressing a 
dead key twice usually writes the accent mark alone, though in the case of 
~, it's not necessarily at the same height (old computers used to draw the 
~ sign higher so that it could be really put on top of a lowercase).


Portuguese and German kezboard lazout have such a dead kez.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] ordering arrays based in similarity

2012-03-04 Thread Mathieu Bouchard

Le 2012-03-05 à 01:37:00, ronni montoya a écrit :


How can i order each one of these arrays (messages) based in its
similarities? i need that the most similar ones can be neighbours, so
i can trigger them in a ordered way
how can i achieve this?


Similarity is not just one concept, it's a wide variety of related 
concepts. You need to figure out in which manner you'd do it. First look 
at which combinations you would like to be considered completely 
equivalent, or very much equivalent.


e.g. is the list 1 23 456 7890 as very much like the list 456 7890 1 23 ? 
If so, why ? (there are several possible reasons, very different from each 
other)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] Music Notation in linux

2012-03-04 Thread Mathieu Bouchard

Le 2012-03-03 à 22:54:00, Lorenzo Sutton a écrit :

You can create a midi output, with all the drawbacks and benefits. As 
far as I know there is no lilypond player, but to be totally honest 
I'm not sure it would make so much sense as lilypond is primarily a 
music typesetting language.


Do you also mean it doesn't make much sense to use PureData for anything 
else than audio ?


And computers were only meant for doing math, too.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-03-03 Thread Mathieu Bouchard

Le 2012-02-27 à 10:34:00, IOhannes m zmoelnig a écrit :

On 2012-02-26 19:50, Mathieu Bouchard wrote:

Or else just discontinuing the MSVC edition...


no.


Why do you need to keep a MSVC edition, again ? You probably told me 
already, but I don't remember.


Are there libraries that people use with GEM that require MSVC and can't 
work with MinGW ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-03-03 Thread Mathieu Bouchard

Le 2012-03-02 à 13:32:00, katja a écrit :

How about function call overhead? For constructor and destructor no 
problem of course, but accessor wrappers will be called often, in fact 
it doubles the number of function calls for external access.


Constant calls are possibly a lot quicker than variable calls. Pd does 
call by function pointer, which needs to be figured out before the CPU 
pipeline can start reading and parsing the machine-code for it. When it's 
just a function-pointer in a known variable, it's not very slow, and might 
be very fast (?), but it takes a lot more time if there are conditional 
statements necessary to figure out which function-pointer should be used. 
This should tell you a lot about Pd's message-passing if you read that 
part of Pd.


A wrapper that is specific to each method is very fast, because the 
pointer is already known.


GridFlow uses two levels of wrappers, one of which is supposed to be slow 
according to what I say above (because the outer wrapper does its own 
message dispatch) ; but keeping things in perspective, it's still faster 
than anything else in Pd, when it comes to doing things that no other Pd 
class provides.


GEM's wrappers have virtually no runtime overhead, except that wrapper has 
to be written. GridFlow's method-wrappers are auto-generated, so that you 
don't have to write them. Those are two big examples of wrapping a C++ 
library in C so that it can be used in Pd.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-03-03 Thread Mathieu Bouchard

Le 2012-03-03 à 10:32:00, katja a écrit :

I fail to see how those C wrappers could be inlined. Wouldn't that undo 
their raison d'être (replacing a C++ call with a C call)? But indeed 
function call overhead is small when compared to number-crunching, if 
these calls are done per block and not per sample.


If a function is only called from a single location and the function is 
hidden, then the original function may disappear and become embedded into 
the wrapper. I don't see GEM hiding its classes in such a manner. What 
might happen instead, is that a lot of code gets duplicated into the 
wrapper. This makes the executable bigger, but you still get the extra 
speed from inlining that way (for small functions).


The « omit frame pointer » optimisation may cut a lot of the overhead 
while reducing code size, for function calls that are not inlined.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Gem/Gridflow with PdDriod Party ...possible?

2012-03-03 Thread Mathieu Bouchard

Le 2012-03-01 à 12:23:00, ALAN BROOKER a écrit :

I've been playing around with the very excellent PdDriod Party and I was 
thinking if there was a way to have visuals incorpertated into the 
patchs with Gem/Gridflow? I am may tryout impeding libpd into a 
processing andriod sketch but wanted to just enquire about Gem/Gridflow 
:]


When I started trying to port GridFlow to Android in 2010, I quickly hit a 
wall, but I did not try for long.


Now I have a lot more knowledge of Android, so I might have better luck, 
or not ; but I'm not currently planning a port to Android, though if 
someone wants to try it, I could help a bit.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] save search path 0.43 OSX

2012-03-03 Thread Mathieu Bouchard

Le 2012-02-27 à 18:31:00, IOhannes m zmoelnig a écrit :

On 2012-02-27 18:22, Jonathan Wilkes wrote:

Sorry for the obscure example, but I think it's important for abstractions to 
have some way
of accessing class-wide data-- like this:

you mean something like [1]?
[1]
https://sourceforge.net/tracker/?func=detailaid=1403917group_id=55736atid=478072


It's related, but the need is for something that doesn't depend on the way 
it's written : if [import shadok] then [shadok/gibi] and [gibi] might be 
the same, but will use different receive-symbols.


But more importantly, what you suggest is for accessing all canvas-objects 
that are of a same abstraction-class, which is not the same as sharing 
various properties that belong to a certain abstraction-class.


I mean that the canvas-object used to make an abstraction-object is not 
the same as the abstraction-object itself. The canvas-object does not 
directly handle stuff that is implemented in pd, and its receive-symbols 
are really about canvas-responsibilities.


So if an abstraction pretends to be a canvas using [receive] in an attempt 
to extend the list of methods that the object supports, then every message 
not meant for the canvas will cause « canvas: no such method ».


An abstraction-object's canvas object, even though it represents the 
object itself, usually shouldn't be talked to directly from outside, as 
the abstraction-class is what is supposed to know whether and how 'vis', 
'coords', etc., should be used.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] Music Notation in linux

2012-03-03 Thread Mathieu Bouchard

Le 2012-02-28 à 11:42:00, Lorenzo Sutton a écrit :

I think this can be mitigated by using some gui programme which can then 
export to lilypond. It does add an additional passage to the chain but 
can be useful for editing the music. E.g. I have used Rosegarden (which 
is mainly a sequencer and has the advantage of playing the music).


Is there any programme that can play a .ly file, using some reasonable 
expectations of what « staccato » means, et cætera ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] openstomp ... PD pedal?

2012-03-02 Thread Mathieu Bouchard

Le 2012-03-02 à 12:27:00, m.e.grimm a écrit :


http://www.parallax.com/Portals/0/Downloads/mm/audio/Coyote1%20Demo.mp3
worst music ever.


You need not inform us that you found out that it is.

It mostly just informs us that you are underexposed to bad music to the 
point where you can't distinguish plain boring music from something worse 
than just boring.


  http://museumofbadart.org/coll1/image01.jpg

But to me, there is very little difference of excitement between this 
mp3's music and most electroacoustic music, though for completely 
different reasons.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] openstomp ... PD pedal?

2012-03-02 Thread Mathieu Bouchard

Le 2012-03-02 à 13:40:00, m.e.grimm a écrit :

yes. you are completely right. i am going to go buy myself a television 
right now to remedy the situation.


You can already get all the bad music you want on Youtube.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] openstomp ... PD pedal?

2012-03-02 Thread Mathieu Bouchard

Le 2012-03-02 à 13:51:00, m.e.grimm a écrit :


i guess i will have to buy a computer too then. walmart is on my way home.


I suggest a PDP-11/34, the state-of-the-art in miniaturisation.

http://www.flickr.com/photos/39042368@N04/5807719935/sizes/l/in/photostream/

Doesn't even fill the rack !

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [OT] openstomp ... PD pedal?

2012-03-02 Thread Mathieu Bouchard

Le 2012-03-02 à 17:37:00, Billy Stiltner a écrit :


you should be able to get a 486 on a pinhead these days


How many 486 can dance on the head of a pin ?

http://en.wikipedia.org/wiki/How_many_angels_can_dance_on_the_head_of_a_pin%3F

486dx, of course.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] dsp graph question

2012-03-01 Thread Mathieu Bouchard

Le 2012-03-01 à 12:02:00, Jonathan Wilkes a écrit :

And is it possible to make local symbol tables that are separate from 
the global symbol table?


Look into my proposals that I wrote back in 2006 or so, probably on 
pd-dev. But I don't think I got any replies on them at all.


Additionally, if an array of scalars only send the signal to the 
[struct] signal outlet and don't interact with each other (through 
[send~], [throw~], [etc.~]), could one could use [setsize] to to do 
massive polyphony without having to rebuild the entire graph?


DSP graphs allow dsp-methods to call dsp_add with all sorts of very 
context-specific arguments such as direct pointers to the internals of 
tables and of delwrite~ and such. To make those into context-independent 
things would require a lot of work. But you don't necessarily need to do 
that if all you want is just to avoid most of the recompilation whenever 
you add or remove a few abstraction instances at any given moment.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] dsp graph question

2012-03-01 Thread Mathieu Bouchard

Le 2012-03-01 à 14:33:00, Jonathan Wilkes a écrit :

Oh interesting-- there's an entire thread on namespaces for 
send/receive.  Never noticed that before.


From 2006 all I see is some stuff about deallocatable symbols-- is that 
what you're referring to?


That's an approximate year. There are probably several threads on the 
topic(s). I remember writing about deallocatable symbols in more recent 
years, but the thing that I think was in 2006, is about splitting the 
receive-table away from the symbol-table so that receive-symbols could 
become local : have a global t_symbol * but have a local s_thing. Then 
receive-symbols wouldn't necessarily be symbols anymore, they'd be pairs 
of one $0 and one t_symbol *... I'm reinventing this in my head as I write 
it, maybe.


It's possible to fit a very large $0 in a_type because most values of 
t_atomtype aren't taken. For example, all negative values of t_atomtype 
could be reserved to mean the local-symbol where $0 = -a_type.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Pd on ARM devices

2012-02-29 Thread Mathieu Bouchard

Le 2012-02-29 à 17:06:00, Pierre Massat a écrit :


I'm planning to buy a Raspberry Pi sometime soon, and I'd like to know the 
implications of the ARM11 chip on the use of Pd.
I know nothing about the differences in architectures, so i'd like to know :
- why an ARM chip would be a problem for compiling, installing and running Pd,
- if there exists another option that's up to date (Pda seems a bit old),
- if Libpd could be used instead (given that i only want to run Pd patches on 
the Raspberry Pi, I don't need to edit anything on it).


At work, I use an iPhone ARM7, and an Android ARM7, with basically the 
same libpd build on each.


I'm using it through the m_pd.h interface as much as possible instead of 
libpd's own ; either can be used.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] save search path 0.43 OSX

2012-02-27 Thread Mathieu Bouchard

Le 2012-02-27 à 16:44:00, Roman Haefeli a écrit :

On Sun, 2012-02-26 at 11:50 -0500, Mathieu Bouchard wrote:

Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :

On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:

Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :

In what way [import] shouldn't be used inside abstractions?

[import] is not very local, is it ?

But it also works with multi-class externals. See my other mail.

But it's not very local, is it ?

I got it (why are you repeating it?)


Because my point is that it doesn't import names of externals locally. So 
if it's not local, then it doesn't really matter that it does the same (?) 
with multi-class externals, because that's not what it should do.


Fortunately, nameclashes are a relatively rare occurrence, otherwise we'd 
more often hear things like « restart pd in order to avoid nameclashes 
caused by [import] being present in patches that have already been 
closed ».


[zexy/dirac~] just simply doesn't work on a Debian box that has puredata 
and pd-zexy installed. It seems that [zexy/dirac~] adds 'dirac~' to the 
global namespace, not 'zexy/dirac~'. At least, when I create 
[zexy/dirac~] in a patch in Pd-extended, I can create instances of 
[dirac~] afterwards.


So, is this a bug in Zexy, or a bug in the way «namespacing» is 
implemented ? What does this case prove ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] choosing your language at launch WAS: Japanese Pure Data book is out now.

2012-02-27 Thread Mathieu Bouchard

Le 2012-02-27 à 10:25:00, Hans-Christoph Steiner a écrit :

I haven't included the latest yet.  If you are on GNU/Linux or Mac OS X 
with Fink or Macports, its easy to generate your own ja.msg file for 
Pd-extended to use.  Let me know and I can walk you throw the process.


BTW, I realised (or remembered ?) that on OSX, the LANG syntax is a bit 
different from what it is on GNU/Linux.


For example, fr_CA.utf8 has to be written fr_CA.UTF-8 instead, uppercase 
and hyphen.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Toonloop/Stop Motion in Pure Data

2012-02-27 Thread Mathieu Bouchard

Le 2012-02-27 à 12:00:00, Antonio Roberts a écrit :

Has anyone attempted to make something like Toonloop 
(http://toonloop.com/) in Pure Data? It's basically a live stop motion 
tool.


The basics of it should be a quite small GF patch (or GEM) if you try to 
make one.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Toonloop/Stop Motion in Pure Data

2012-02-27 Thread Mathieu Bouchard

Le 2012-02-27 à 17:28:00, Antonio Roberts a écrit :


Thanks. Do you have any example patches to work from?


Dunno... find something with a 4-dimensional [#store] : there are some 
examples that use such multi-frame buffers for making delay-based effects. 
Those can be recorded to at any speed, and the speed is implicit : you 
always store in terms of one grid that you put into another grid (or in 
place of another grid), so you control frames one by one and can make 
single snapshots easily.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] save search path 0.43 OSX

2012-02-27 Thread Mathieu Bouchard

Le 2012-02-27 à 12:11:00, Jonathan Wilkes a écrit :


Any idea what Miller's comment means by a control inlet for canvases? 


It means that mysterious remarks made six years ago should be disregarded.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] save search path 0.43 OSX

2012-02-27 Thread Mathieu Bouchard

Le 2012-02-27 à 12:58:00, Jonathan Wilkes a écrit :

From: Mathieu Bouchard ma...@artengine.ca
It means that mysterious remarks made six years ago should be disregarded.
But what if this mysterious control inlet could be the key that unlocks the 
door to Maximus P?  How long must we [bang(--[until] we reach the promised land?


I don't know. I don't want to go to Maximus P.

Isn't Maximus P an optional side quest ?

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] save search path 0.43 OSX

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-26 à 11:50:00, Roman Haefeli a écrit :

On Fri, 2012-02-24 at 15:16 -0500, Mathieu Bouchard wrote:

Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :

In what way [import] shouldn't be used inside abstractions?

[import] is not very local, is it ?

But it also works with multi-class externals. See my other mail.


But it's not very local, is it ?

Where does it import symbols to ? A big global namespace.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-22 à 13:51:00, Jonathan Wilkes a écrit :

It looks old and unmaintained, and I doubt it supports the newest 
version of Qt which has introduced the graphics view stuff


What's the graphics view stuff ?

If Qtcl works well, it could be a possible path for speeding up the GUI, by 
replacing Tk entirely, but keeping Tcl (which is easier than changing everything 
at once). But there are other paths (the ones I suggested recently).


The only other path I remember is patching Tk to make it more efficient, 
but you still wouldn't get zooming with that.


I also mentioned the use of binary protocols, but it depends how much the 
binary protocol removes the Tcl dependency. A light use of binary elements 
means efficiently cutting the stream into Tcl commands to be run, and also 
ability to transmit raw data (array coords, images) at higher speed. But 
if that path is followed further, then... well, there are dozens of 
possible ways of making things more modular and it's not necessary to 
enumerate every possible way of doing so.


Tk zooming can be achieved using a TkCanvas wrapper that filters all 
coordinates. I'd use poe.tcl and follow a structure similar to Chun's 
TkZinc wrapper experiment and «def Canvas item» at once.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-25 à 09:55:00, Andy Farnell a écrit :

Shortcuts made because a language is compact and elegant only pay off 
where you write millions of lines of code.


Who knows, maybe they don't pay off ever. :-P

You don't need to spit out that kind of gratuitous nonsense.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-25 à 23:44:00, katja a écrit :

I do not use STL functionality, libstdc++ seems to be required for other 
functions as well, and vanilla Pd can't load a C++ object without it.


If you really want to avoid libstdc++, I think that you can do something 
like :

#include malloc.h
static inline void *operator new (unsigned int n) {return malloc(n);}
static inline void operator delete (void *p) {return free(p);}

and add -fno-rtti to the flags (to disable the typeinfo feature). If you 
encounter anything else, just ask me and I'll try to find it.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] OT - C++ for reusable dsp lib - or better use C?

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-25 à 14:29:00, Phil Stone a écrit :
IMO, Pd *approaches* this potential of live-coding, but isn't there yet. The 
edit/play dichotomy,


The Edit/Play modes are there just to allow more different mouse commands. 
It's not really a feature of the engine, it's just for switching between 
two sets of mouse behaviours in the GUI, because there are not enough 
buttons.



I also like programming in word languages,


For what I presume you call a non-word language, Pd has quite a large 
vocabulary of words in it.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] OT - C++ for reusable dsp lib - or better use C?

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-25 à 17:49:00, Hans-Christoph Steiner a écrit :

I agree that instant feedback is very important, that's a big reason why 
I use Pd.  I wonder if he's ever used Pd.  Pd has been providing a lot 
of that experience for almost 2 decades now.  The one thing in it that 
Pd does not provide is the ability to click on the generated image in 
order to see which code is generating that part of the image.  That 
would be a nice feature to have.  But I can't see how you would 
generalize beyond drawing pictures.


It can't even generalise to all images. There's an OpenGL feature whether 
if you get a mouse position, you can tell the OpenGL engine to find any 
geos that contain that (x,y) location while drawing the next frame. I 
forgot what the name is and I never used it.


But this can't possibly tell you anything about the construction of Gem 
pixes or GridFlow grids, in which solutions range from complicated to 
impossible, especially because a lot of objects modify all pixels in the 
image at once, but also because even for more localised edits of images, 
the objects currently don't track that info and it would take lots of work 
to make them do so... or create an image diff tool that would be very 
slow.


Most ~-objects also operate on the whole signal.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-22 à 08:42:00, IOhannes m zmoelnig a écrit :

On 2012-02-22 06:46, Mathieu Bouchard wrote:

So, are you switching GEM away from MSVC, or are you going to make a C
API so that GEM can actually collaborate with other Pd-based frameworks
that want to read its data on Windows ?

well, yes; i'd like to


Well, let's say that this interface is only for supporting pixes in other 
frameworks without having to go through [pix_data] and [pix_set]. What 
would you put in it ?


Some kind of permanent interface for getting/setting xsize, ysize, csize, 
upsidedown, type and format ; something to see whether there's a pix at 
all, something for creating one, and some explanation of how 
newimage/newfilm is supposed to work...


And a try/catch in every wrapper to protect against exception problems 
between MSVC and GCC.


Or else just discontinuing the MSVC edition... which thing do you mean 
when you say that you would « like to » ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] OT - C++ for reusable dsp lib - or better use C?

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-26 à 10:53:00, Phil Stone a écrit :

On 2/26/12 10:29 AM, Mathieu Bouchard wrote:

Le 2012-02-25 à 14:29:00, Phil Stone a écrit :

I also like programming in word languages,


For what I presume you call a non-word language, Pd has quite a large 
vocabulary of words in it.


I'm pretty sure you, and most readers of this list, understand the 
distinction I am making between graphics-dominated and text-dominated 
programming environments. Perhaps the scare quotes should be a tip that I'm 
not speaking in exactitudes at that moment. :-)


I know, but I still think that it was worth mentioning, just like I'd 
doubt that Pd is that much graphics-dominated... I know the distinction 
you're trying to make, and the graphics part of Pd is what we notice the 
most, but there's an awful (or awesome) lot of text in there. It's nice 
like that, though. I wouldn't trade a language to get a bucketful of 
icons. More often than not, one word is worth a thousand pictures.


We won't be able to find what % of importance the graphics have in Pd in 
comparison to plain-text languages, but this time, I just want to point 
out that graphics in Pd look like they're dominating only because we're 
used to have text take nearly all the room.


I don't necessarily have good replacement adjectives to provide you with.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] save search path 0.43 OSX

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-26 à 14:11:00, Hans-Christoph Steiner a écrit :

On Feb 26, 2012, at 11:50 AM, Mathieu Bouchard wrote:

Where does it import symbols to ? A big global namespace.


Yup, binary objects will be imported into the global namespace. 
Abstractions will be local though.


Oh, yes, because abstractions are never listed as part of pd_objectmaker : 
only externals are.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] MIDI input problems in PD

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-26 à 13:11:00, Miller Puckette a écrit :


I don't have any real MIDI devices, just USB keyboards that fake MIDI,


That's a matter of ontology. What is reality ? I mean the real reality.

Politically correct Wikipedia instead calls USB an « Alternative hardware 
transport » for (real) MIDI.


http://en.wikipedia.org/wiki/MIDI#Alternative_hardware_transports

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pd mentioned in squarepusher interview

2012-02-26 Thread Mathieu Bouchard

Le 2012-02-27 à 11:14:00, i go bananas a écrit :

right at the very end of this 10 minute interview, Tom mentions PD 
(while showing off his reaktor patches, though :p )


I don't know whether you get the same subtitles as I do, but in the French 
subtitles, it says « PD, Reactor ou Maximus P ».


Maximus P ??

lol

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] OT - C++ for reusable dsp lib - or better use C?

2012-02-25 Thread Mathieu Bouchard

Le 2012-02-25 à 12:32:00, patrick a écrit :


I wish I could code an external like he's coding:
http://vimeo.com/36579366


you're not mentioning which part of this extremely long video you are 
referring to, and this player does not allow skip-ahead, which means I 
can't fast-forward faster than the download speed of the whole thing. This 
is why I won't try to figure out what you mean.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] sigmund list sort

2012-02-25 Thread Mathieu Bouchard

Le 2012-02-25 à 09:34:00, Frank Barknecht a écrit :

Yes, exactly. I often use data structures, well, as data structures and 
almost never use them for scores in a UPIC sense.


What's UPIC ?

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] sigmund list sort

2012-02-25 Thread Mathieu Bouchard

Le 2012-02-25 à 09:45:00, Frank Barknecht a écrit :

On Sat, Feb 25, 2012 at 09:38:20AM +0100, Frank Barknecht wrote:

On Fri, Feb 24, 2012 at 01:26:54PM -0500, Mathieu Bouchard wrote:
 I don't know any more recent version of list-abs.
To me the home of [list]-abs is the CVS repository, 

Oops, SVN of course. At Sourceforge.


Do you mean RCS, or do you mean SCCS ?

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-25 Thread Mathieu Bouchard

Le 2012-02-22 à 15:30:00, katja a écrit :

Pd classes can be done in C very well, if procedures are not too 
complicated and not meant to be used in other contexts.


In my practice, C is not high-level enough. So, for coding my own C++ 
externals, I use C++ together with a custom preprocessor which does a job 
similar to what SWIG does.


For a reusable audio analysis lib I would straightforwardly use C++, 
where it not for the considerations mentioned by Mathieu, Hans and 
Marvin. The intricate runtime support required for C++ leads to specific 
incompatibilities which don't exist for C.


IMHO, fighting those incompatibilities is worth it ; also, some of them 
don't exist anymore (in recent years), and some others have a workaround 
whenever you provide a C interface to a C++ library, and some others don't 
exist if you turn off try/catch/throw support.


A collection of useful routines which may be used individually, or 
combined as integrated analysis-engine, in the context of a framework 
like Pd, MaxMsp, SuperCollider.


Can you be more specific about what this will be ?


I use to link GNU C++ standard libs statically, just in case my class
is used with a Pd which doesn't have them. This adds more than 100 KB
to the executable size, not so nice detail.


Isn't this mostly when you use STL ? The use of STL is optional. For 
example, I almost never use #include fstream in C++, I still prefer 
stdio.h.


A C lib would not impose all these concerns on an application 
programmer. I'm inclined to look at C once more.


Instead, a C lib will impose other concerns that C++ won't. What will 
those be ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-25 Thread Mathieu Bouchard

Le 2012-02-25 à 01:58:00, katja a écrit :

I'll do it the hard way, plain C. I've rewritten one of my own C++ 
library classes into C by way of exercise and comparison. It does 
exactly the same thing at the same speed, with not so sweet-looking 
code. This doesn't cover all the C/C++ differences, but in the end, 
everything can be solved in C one way or another.


It's not a strict matter of beauty of code. The reason why programmers 
talk so much about the beauty (or cleanliness) of the code, is because of 
the practical qualities. But the appreciation of beauty or cleanliness is 
something that evolves with time... depending on one's experience of what 
matters and what doesn't.



In my (not so huge) coding experience, I've always noticed that code
typing is the least time consuming aspect of a dsp project. To figure
out a good concept takes longer. Testing and bug fixing takes longer.
Optimization takes longer. I've once written an optimized FFT lib (in
C). It took me a month if I remember well, and that was not because of
all the code typing.


If you have to write twice more characters to do the same thing in C as in 
C++, then you will have to read twice more characters when you want to 
review the code, debug the code, or just re-understand the code later. If 
you optimise your code or reorganise your code, then you will need to read 
twice more AND rewrite twice more. But that's not that much compared to 
the effect of having to think about cluttered sentences of code.


That's just an example. Some C is the same length as the C++ equivalent. 
Some other C is 3, 4 or 5 times longer than the C++ equivalent, sometimes 
worse.


As a conclusion, a famous quote :

« There are two ways of constructing a software design; one way is to 
make it so simple that there are obviously no deficiencies, and the other way 
is to make it so complicated that there are no obvious deficiencies. The 
first method is far more difficult. »


 — Antony HOARE (alias Mr. QuickSort)

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] OT - C++ for reusable dsp lib - or better use C?

2012-02-25 Thread Mathieu Bouchard

Le 2012-02-25 à 13:14:00, Phil Stone a écrit :


It's well worth watching, all the way through. It was a eureka moment 
for me -- I now see the potential of live-coding.


Ah ok, you mean that you didn't see the potential of live-coding by using 
PureData ?


But PureData isn't just about the potential of live-coding. It's also 
about doing it. Possibly even every time you use it.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pix_openni crash Pd

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 18:10:00, Jack a écrit :


Here the output with valgrind when i create the gemwin :


Are there any « Invalid write » messages before getting there ?

Also note that GEM 93 and GEM 92 are quite binary-incompatible, therefore 
an external has to be compiled with the right set of .h files.


There were also at least two more intermediate steps for those who used 
SVN versions of GEM 93. For example, GridFlow supports GEM 92 and two 
early kinds of GEM 93 but doesn't work with the final GEM 93.


I'm talking about this because :


Address 0x735ef68 is 0 bytes after a block of size 32 alloc'd
at 0x4025315: calloc (vg_replace_malloc.c:467)
by 0x80B8710: getbytes (in /usr/bin/pd)


Looks like an object has an unexpected size, which hints at possible 
mismatching struct{} definitions.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [PD-announce] Japanese Pure Data book is out now.

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 10:53:00, Julian Brooks a écrit :

So in a wonderfully circular twist: Any chance of an English ebook 
translation (preferably free, of course)?


Why aim for just free, when you can aim for getting paid to read it.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Resonant filter using cpole~ czero~

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 09:07:00, Frank Barknecht a écrit :

I made it half signal-rate: The object accepts signal parameters, but 
these are just linearly interpolated internally, i.e. they don't move 
correctly on a circle.


If you interpolate, it means that you are doing something at non-signal 
rate. What is it that makes you having to interpolate a signal parameter 
that is already at the same rate as the main input ?


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] sigmund list sort

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 09:51:00, Miller Puckette a écrit :


It's odd, but it never occurred to me that one should be able to specify
which field(s) to sort on -- it's x, then y.  I should fix this...


Nearly all the music I ever composed used a vertical time axis. Lots of 
people are in this situation, though perhaps not many are also into Pd DS.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] sigmund list sort

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 09:02:00, Frank Barknecht a écrit :

On Sat, Feb 18, 2012 at 01:14:22PM -0500, Mathieu Bouchard wrote:

the [list-sort] abstraction uses a high-constant O(n²) algorithm that
breaks once you try to sort more than 125 values.

Actually [list-sort] since quite some time uses the sort method borrowed from
Pd's data-structures for sorting.


I have Pd-extended 42.5 that contains Michał Seta's sort, which used to be 
cubic (O(n³)) and with even lower sorting limits, until I made you replace 
the O(n²) [list-drip] that used O(n) stack, by one that runs in O(n) and 
uses O(log n) stack.


I don't know any more recent version of list-abs.

The problem here is not so much the sorting algorithm, which is very 
fast and can sort way more than 125 items.


Indeed, it's a slow version of mergesort written using linkedlists in C, 
which is still faster than nearly anything one could possibly come up with 
in pure Pd.


However copying the list to a data structure and back - this currently 
indeed has a problem with stack-overflows, as I'm now aware. Have to 
think about a fix ...


Make sure that your algos take less than O(n) stack space... If it's not a 
125 element limit, it's 500 or 1000, and it can't get higher without 
recompiling Pd to be more indulgent.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] save search path 0.43 OSX

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 20:57:00, Roman Haefeli a écrit :


In what way [import] shouldn't be used inside abstractions?


[import] is not very local, is it ?

As long as the constructor-table is still one big table (the method-list 
of the objectmaker class), you can't escape the fact that importing any 
set of names «in» an abstraction or any patch, is going to import in the 
global namespace instead, and potentially conflict with anything imported 
by anything else that you wanted to avoid conflict with.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] [PD-announce] Japanese Pure Data book is out now.

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 20:56:00, Julian Brooks a écrit :

On 24 February 2012 17:44, Mathieu Bouchard ma...@artengine.ca wrote:

Le 2012-02-24 à 10:53:00, Julian Brooks a écrit :
So in a wonderfully circular twist: Any chance of an English ebook 
translation (preferably free, of course)?

Why aim for just free, when you can aim for getting paid to read it.

You offering?  Or do I have to wait for that fantasy academia post.


No, I'm just thinking that you could apply as a reviewing consultant for 
the English translation of the book.


(DISCLAIMER : this email does not count as an endorsement of any kind. It 
also does not count as the opposite of one. I am not responsible for any 
use anyone makes of this email, including but not limited to... et cætera)


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] choosing your language at launch WAS: Japanese Pure Data book is out now.

2012-02-24 Thread Mathieu Bouchard

Le 2012-02-24 à 16:56:00, Hans-Christoph Steiner a écrit :

For the geeks, you can select the language easily when launching Pd from 
the terminal.  This is what I do for testing the language support:

$ export LANG=en
$ /usr/bin/pd-extended


Just setting the 2-letter language code is usually wrong, because most 
people want to also have the country code and encoding as well. For 
example :


export LANG=fr_CA.utf8

selects French, Canada and Unicode UTF-8 all at once.

 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-22 Thread Mathieu Bouchard

Le 2012-02-22 à 09:37:00, Hans-Christoph Steiner a écrit :


STL, Qt, and Boost are all only used in C++.


Qt is also available for Ada, C#, D, Haskell, Harbour, Java, Lisp, Lua, 
Pascal, Perl, PHP, Python, QML, R, Ruby, Scheme, ... and even Tcl.


See http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings

now for the others...

STL and Boost are different. While Qt's interface (API) consists of 
features that are in many languages (or have very close equivalents), STL 
uses several features that are quite C++-specific and at odds with how 
other programming languages work. Other languages have already their own 
library covering the same ground as the STL, though usually in a quite 
different way and usually not that efficiently. Boost goes further in the 
direction of using all the C++ features that exist and it's at least as 
impossible to port.


This shows a rift between libraries with least-common-denominator 
interfaces that are somewhet easy to port to many languages (incl Qt), and 
libraries that are deeply entrenched in a language to get the best of it. 
The latter is more common in C++, because least-common-denominator tend to 
be a same small set of data types (int,float,string,array), basic OOP 
features, and that's all, while C++ has long expanded beyond « C with 
Classes » to include templates and stuff.


Templates can't be easily wrapped because their point is to generate code 
on-the-fly as the programmer is programming. Wrapping that kind of library 
means reducing the flexibility and/or efficiency, by precompiling some 
use-cases of templates, and forbidding the rest. Otherwise, you'd need 
something that can recompile C++ templates on-the-fly in another language, 
and I haven't seen that yet.


Actually, one can do similar tricks in plain C with macros, but those same 
caveats appear as with templates.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-22 Thread Mathieu Bouchard

Le 2012-02-22 à 13:59:00, august a écrit :


It's an OOP language ( looks like  C#) that compiles down to OOP C.


BTW, early C++ compilers also used to compile to C, but that feature was 
«removed» long ago. Nearly none of the well-known compilers have ever 
implemented it. I think that C++ was mostly compiled this way from 1979 
until approx 1987, long before I ever heard of it, and before nearly 
anyone had heard of it.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Tk Zoom

2012-02-22 Thread Mathieu Bouchard

Le 2012-02-22 à 09:31:00, Hans-Christoph Steiner a écrit :

On Feb 22, 2012, at 12:48 AM, Mathieu Bouchard wrote:

How do you do zooming with Tcl/Tk ?
I mean... I implemented zooming using a big workaround which wouldn't have 
worked with Pd externals... is there a trouble-free way to zoom ?


Didn't you use Tk scaling?  That's what I mean. Yes, this would not work with 
existing GUI objects.


« Tk Scaling » is the name of a font measurement ratio for pt/px 
conversions, right ?


TkCanvas' «scale» command is unrelated, and does not do zoom, because it 
changes the size of items. The difference between that and zoom is that Tk 
doesn't make you see the prescaled coordinates, it still interacts with 
you only in terms of actual pixels. This means that most of the time, 
you'd have to scale the values on your own using [expr {$x*$scale}] and 
stuff.


In DesireData, I avoid TkCanvas's «scale» command entirely, and I make 
every canvas item creation/modification through a function that scans the 
arguments of the item, scales all coords it sees, scales the thickness of 
lines, scales the font sizes, automatically decides tags to be used, and 
figures out what to do differently in create vs modify.


That way, the widget's behaviour does not have to implement zoom, it does 
not have to implement modification-functions (because the create-function 
is able to redraw an existing thing), it does not have to implement the 
delete-function (because the enforced common tag makes a single command 
delete), etc.


That's not compatible with t_widgetbehavior and couldn't possibly be made 
to be.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-22 Thread Mathieu Bouchard

Le 2012-02-22 à 19:25:00, august a écrit :

The GObject method is pretty clever.  It allows you to abstract objects 
in an XML format.  Then, based on those abstractions, you can introspect 
them for their behaviour and link them into almost any language.


I wonder how difficult it would be to do something like that with PD's object
system?


You can already inspect several aspects of Pd objects and classes, at 
runtime, without having to read any XML at all. However, this info is not 
especially complete : in particular, classes don't contain lists of 
methods for non-first inlets, and there is no class-table, only a 
constructor-table, so you need an object to be instantiated before you can 
access a class. Also, method signatures are often limited to A_GIMME for 
lack of ability to say it differently.


That's except for pd classes that go through GridFlow's C++ interface. In 
that case, there's a central class-table, from which you can find all 
method-names for all inlets. Method signatures (argument types) are not 
available but this feature could be added to the system without modifying 
any class. Each class also has a list of attributes, which gives you at 
least type info for *some* of the methods.


There are some other exceptions like that as well, having to do with 
various bridges between one language and Pd.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] C++ for reusable dsp lib - or better use C?

2012-02-22 Thread Mathieu Bouchard

Le 2012-02-22 à 07:58:00, Krnk Ktz a écrit :

You could also consider not to use OOP. It has become very fashionable 
because of Java and C++, but there other paradigms working very well.


OOP is not a matter of fashion. There's a fashion aspect about it, but 
that shouldn't prevent you from seeing the core principles of it. OOP is 
not necessarily a paradigm either : its core concepts can be ported from 
«paradigm» to «paradigm» to create more new «paradigms». It has already 
gone well beyond imperative languages. I don't consider C++/Java to be in 
a different paradigm than C, because they all use the concept of storage 
that gets read and written along a timeline of programme steps that have 
to be run one after the other in the order specified by the programmer.


C has been working for decades; why would you want to use it in a way it 
has not been conceived for?


Every programming language worth being calling that way is conceived to be 
used in ways it has not be conceived for.


There's also a big difference between what something is made for, and what 
it's good for.


Note that C is extremely often used for constructing interpreters for 
languages that are especially good at things that C isn't good at.


The activity of programming doesn't fit in narrow boxes of Paradigms and 
of Intended Purposes.


 __
| Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


  1   2   3   4   5   6   7   8   9   10   >