[PD] Altova Mapforce

[Mathieu Bouchard]

If that may reassure you... not only Pd has messes of uncooked spaghetti 
going under boxes and stuff. And not only dataflow diagrams have them. 
This is an example in a data-relational diagram in a database app :


http://www.altova.com/images/landing_page/mapforce_screenshot_large.png

And cooking the spaghetti softens the spaghetti but it's still spaghetti.

OTOH, it would be a lot more readable already if the middle boxes were 
just placed in proper places...


 __
| 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] patching circles other than New York

[Richie Cyngler]

I feel just like you Jim so we will be starting a general patching circle
in Melbourne Australia (maybe still a little out of your way) very soon!
The focus is pretty broad audio-visual experimental open source
software/hardware, whatever platform(s) you like.

The venue will probably be Melbourne Hackerspace (in Hawthorn). Looking for
more interest at the moment, anyone reading this and in Melbourne and
surrounds should get in touch.

cheers

On Thu, Feb 23, 2012 at 1:36 PM, Hans-Christoph Steiner wrote:

>  On 02/19/2012 05:53 PM, Jim Hickcox wrote:
>
> I am wicked jealous of Sofy's New York Patching circle, because I'm
> just far enough away and just employed enough that I can't get up for
> it.
>
> Are there folks near Washington DC who would like to have a patching circle?
> I will try to organize a space if there are some people into it
> And there can be beer here, too, if that's all it takes.
>
> -Jim Hickcoxwww.jimhickcox.com
>
> ___pd-l...@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>
>
> I am surprised William Brent hasn't chimed in here, he's in DC and was
> talking about the idea at a patching circle in NYC.
>
> http://www.american.edu/cas/faculty/brent.cfm
>
> .hc
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
Richie

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

Re: [PD] patching circles other than New York

[Hans-Christoph Steiner]

On 02/19/2012 05:53 PM, Jim Hickcox wrote:
> I am wicked jealous of Sofy's New York Patching circle, because I'm
> just far enough away and just employed enough that I can't get up for
> it.
>
> Are there folks near Washington DC who would like to have a patching circle?
> I will try to organize a space if there are some people into it
> And there can be beer here, too, if that's all it takes.
>
> -Jim Hickcox
> www.jimhickcox.com
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

I am surprised William Brent hasn't chimed in here, he's in DC and was
talking about the idea at a patching circle in NYC.

http://www.american.edu/cas/faculty/brent.cfm

.hc
___
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?

[katja]

On Wed, Feb 22, 2012 at 7:21 PM, august  wrote:

> Yes, I even wrote an interface file for libpd so you can use libpd to load and
> control pd patches from within vala.
>
> It is part of a larger experimental project I've been working on and have 
> meant
> to post here.  It's called the Underweb.  You can read about it here:
>
>        http://underweb.info/


An impressive project, August. Keeping the web open for all to
actively use it, that is an important issue indeed.


About Vala, it isn't so platform independent, that's a pity. The docs
are decent, there's frequent releases, these are good signs.

Katja

___
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?

[Jonathan Wilkes]

- Original Message -
> From: Mathieu Bouchard 
> To: Jonathan Wilkes 
> Cc: Hans-Christoph Steiner ; "pd-list@iem.at" 
> ; IOhannes m zmoelnig 
> Sent: Wednesday, February 22, 2012 2:03 PM
> Subject: Re: [PD] C++ for reusable dsp lib - or better use C?
> 
> Le 2012-02-22 à 09:05:00, Jonathan Wilkes a écrit :
> 
>> That's great news.
>> 
>> Would you mind giving me the link to the stable, actively maintained 
> library that makes Qt available for Tcl?  I look forward to testing it out.
> 
> I'm not responsible for every project or category of projects that I 
> mention, so I can't guarantee you that any of those wrappers are well-made 
> or worth using.
> 
> Tcl may be one of the lesser languages for Qt. The intersection of Tcl and Qt 
> users is somewhat small, but even so, there are multiple projects about the 
> same 
> thing.
> 
> First look at http://wiki.tcl.tk/2181
> 
> Skip over TclQt, it's a windows binary thing that doesn't come with 
> source (even though it's on SF.net) and it's very old. There's 
> another one named Tq that is supposedly better but it's commercial and 
> probably abandoned.
> 
> Look at Qtcl. The source is at http://sourceforge.net/projects/qtcl/ and I 
> could 
> get it to compile after I installed qmake and libqt4-dev. I didn't try it.

It looks old and unmaintained, and I doubt it supports the newest version of 
Qt which has introduced the graphics view stuff plus probably a lot of other 
changes.  
But I will give it a shot.

> 
> 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.

> 
> __
> | 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?

[Krnk Ktz]

>> 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.

Sorry, I'm no professional programmer (I don't think i'm even good at it!)
but it seems like you are describing a Turing Machine, which includes every
programming language. Every languages builds to ASM (or is interpreted by
some interpreter built to ASM) and therefore use a storage modified over
the course of the time in a specific order. What matters is how you
organise your code, how you think your program. In the end, it will
actually be the same - both C and C++ build to ASM. However, C++ forces you
to think of objects while C doesn't: that's another way of thinking and
therefore another paradigm.


> Every programming language worth being calling that way is conceived to be
> used in ways it has not be conceived for.
>
>
Well, you can write purely functionnal programs in C, but good luck with
that. You can, but I don't think this is what you want to do.

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

But you construct an interpreter for a new language instead of using C the
way you would use this new language. That's how I have always seen
languages: they try to help you to write programs like you think them.
Every language brings you new ways of thinking programs. It seems also
illogical to me to try thinking in a way which is not the one your tool
does.

Again, I am probably wrong - I just would like to understand why.

Thanks!
___
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?

[Mathieu Bouchard]

Le 2012-02-22 à 09:05:00, Jonathan Wilkes a écrit :


That's great news.

Would you mind giving me the link to the stable, actively maintained 
library that makes Qt available for Tcl?  I look forward to testing it 
out.


I'm not responsible for every project or category of projects that I 
mention, so I can't guarantee you that any of those wrappers are well-made 
or worth using.


Tcl may be one of the lesser languages for Qt. The intersection of Tcl and 
Qt users is somewhat small, but even so, there are multiple projects about 
the same thing.


First look at http://wiki.tcl.tk/2181

Skip over TclQt, it's a windows binary thing that doesn't come with source 
(even though it's on SF.net) and it's very old. There's another one named 
Tq that is supposedly better but it's commercial and probably abandoned.


Look at Qtcl. The source is at http://sourceforge.net/projects/qtcl/ and I 
could get it to compile after I installed qmake and libqt4-dev. I didn't 
try it.


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).


 __
| 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?

[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

Re: [PD] Tk Zoom

[Scott R. Looney]

i may be totally out of my depth here as i'm not a programmer but i believe
MaxMSP was able to do zooming through the use of Juce. it certainly wasn't
available beforehand in any of the 4.X series. personally i find zooming to
be one the most massively useful things when editing patches. being old-ish
my eyes definitely have more issues than they used to...

scott

On Wed, Feb 22, 2012 at 10:32 AM, Mathieu Bouchard wrote:

> 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?

[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] Tk Zoom

[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?

[august]

> 
> >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.

That's too bad because it's a great feature to have.

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?


-- 
http://aug.ment.org
GPG: 0A8D 2BC7 243D 57D0 469D  9736 C557 458F 003E 6952


___
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?

[august]

> > Hi Katja,
> >
> > You might want to have a look at a language called Vala:
> >
> >        https://live.gnome.org/Vala
> 
> 
> Thanks for the link, August. Do you happen to use Vala yourself? I'll
> definitely take a deeper look into it.


Yes, I even wrote an interface file for libpd so you can use libpd to load and
control pd patches from within vala. 

It is part of a larger experimental project I've been working on and have meant
to post here.  It's called the Underweb.  You can read about it here:

http://underweb.info/


Vala allows me to experiment much much faster than C or even C++. It has a lot
of great features like anonymous and asynchronous functions.It also gives
me use of all the fantastic free software libs written for GNOME, but are too
hairy to use in C directly.   Benchmarks even show that with -O3 optimization
at the gcc compile stage, programs in Vala are faster than C++ in most areas.

Supposedly, there is even a way to compile it so that GLib and Gobject are not
dependencies, but I haven't looked into that.

-august.

-- 
http://aug.ment.org
GPG: 0A8D 2BC7 243D 57D0 469D  9736 C557 458F 003E 6952


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

Re: [PD] spinning rope simulation

[BanjoBob Faraday]

Hey There

It's wrapped up in a poorly indexed wiki, but 

http://puredata.1bpm.net/doku.php?id=faradaywab1

You'll need all those patches in one folder. But some of the wind sounds there, 
from filtered white noise, might be close to what you need. See if it's any use 
to you.

Andrew


Date: Wed, 22 Feb 2012 17:18:34 +0200
From: umberto.tor...@gmail.com
To: pd-list@iem.at
Subject: [PD] spinning rope simulation

Hi, i need to record the sound of a rope spinning very fast, i was thinking 
that maybe instead of using recordings: how hard would it be simulating this 
kind of sound in puredata? maybe somebody already did something like this or 
maybe theres a library?


any hint would be appreciated



here is the sound

http://www.zshare.net/audio/9913047058df7102/



Umberto


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

Re: [PD] spinning rope simulation

[Jack]

Le 22/02/2012 16:18, umberto torrez a écrit :
Hi, i need to record the sound of a rope spinning very fast, i was 
thinking that maybe instead of using recordings: how hard would it be 
simulating this kind of sound in puredata? maybe somebody already did 
something like this or maybe theres a library?


any hint would be appreciated



here is the sound

http://www.zshare.net/audio/9913047058df7102/



Umberto


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


Hello,

Your link is broken.
++

Jack


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

Re: [PD] getting the ranges from a slider

[Jack]

Le 22/02/2012 17:51, D G a écrit :

Hi guys

Hey Jonathan your patch was very nice, but the get method did not work 
for me. I had already tried it before writing to the list. Is there a 
real way to work this out?


IOhannes

how about: normalize all slider ranges between 0..1 and transform the
output to the desired range only afterwards?
Yes thats what i was trying to avoid. But seems that there is no other 
way.


i always thought, that the MIDI-based default scaling of sliders and the
like was a step back, and that being able to specify the range has
little gain (though of course i use it...)

That could be if seeking to simplify the settings of native gui 
objects in PD.


I agree with you on the MIDI based default... normalized could be 
simpler. Also easier to explain to a person that is just starting to 
learn PD. Sometimes when they ask "why is the range set to 127" you 
end up with a long talk about MIDI to a person that is getting started 
and wants to get his first sound out of PD.


back to the "get"... is there a way to doit?

D


2012/2/22 IOhannes m zmoelnig mailto:zmoel...@iem.at>>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2012-02-21 20:41, D G wrote:
> Hi List
> I have been looking but have not found the way to ask a slider
for the
> ranges it has been set to.
>
> Is there a way to get a slider to print all its propperties?
This will be
> useful to create a tool that makes randomness to any slider for a
> percentage depending on the ranges it is already set to. I
obviously know
> the ranges, but have a huge number of sliders and [knob] objects
so it
> would be painful to try to get them all.
> Also, if such a method exists, the randomic thing I wanna do
could be
> implemented to any object without having to look at ist propperties.
>
> Would appreciate help or leads to workitout.
>

how about: normalize all slider ranges between 0..1 and transform the
output to the desired range only afterwards?

i always thought, that the MIDI-based default scaling of sliders
and the
like was a step back, and that being able to specify the range has
little gain (though of course i use it...)

fgm,asdr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9EnSYACgkQkX2Xpv6ydvS7GwCgpO45m+ngMiU9EHd3lLb5W7Pb
FM8AoOQuzXgGVNP+jz+88rUKCfkiPfSz
=NnuF
-END PGP SIGNATURE-


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



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

Hello,

Here a small patch showing what IOhannes means.
++

Jack




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

Re: [PD] getting the ranges from a slider

[Jonathan Wilkes]

>
> From: D G 
>To: pd-list@iem.at 
>Sent: Wednesday, February 22, 2012 11:51 AM
>Subject: Re: [PD] getting the ranges from a slider
> 
>
>Hi guys
>
>Hey Jonathan your patch was very nice, but the get method did not work for me. 
>I had already tried it before writing to the list. Is there a real way to work 
>this out?

It is only for getting the properties of a canvas (i.e., patch properties).

One could do a similar patch for the iemguis and atom boxes using that type of 
interface, but I haven't 

made one.


-Jonathan


___
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?

[Jonathan Wilkes]

- Original Message -

> From: Mathieu Bouchard 
> To: Hans-Christoph Steiner 
> Cc: pd-list@iem.at; IOhannes m zmoelnig 
> Sent: Wednesday, February 22, 2012 11:44 AM
> Subject: Re: [PD] C++ for reusable dsp lib - or better use C?
> 
> 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.

That's great news.

Would you mind giving me the link to the stable, actively maintained 
library that makes Qt available for Tcl?  I look forward to testing it out.

> 
> 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
> 

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

Re: [PD] getting the ranges from a slider

[D G]

Hi guys

Hey Jonathan your patch was very nice, but the get method did not work for
me. I had already tried it before writing to the list. Is there a real way
to work this out?

IOhannes

how about: normalize all slider ranges between 0..1 and transform the
output to the desired range only afterwards?
Yes thats what i was trying to avoid. But seems that there is no other way.

i always thought, that the MIDI-based default scaling of sliders and the
like was a step back, and that being able to specify the range has
little gain (though of course i use it...)

That could be if seeking to simplify the settings of native gui objects in
PD.

I agree with you on the MIDI based default... normalized could be simpler.
Also easier to explain to a person that is just starting to learn PD.
Sometimes when they ask "why is the range set to 127" you end up with a
long talk about MIDI to a person that is getting started and wants to get
his first sound out of PD.

back to the "get"... is there a way to doit?

D


2012/2/22 IOhannes m zmoelnig 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2012-02-21 20:41, D G wrote:
> > Hi List
> > I have been looking but have not found the way to ask a slider for the
> > ranges it has been set to.
> >
> > Is there a way to get a slider to print all its propperties? This will be
> > useful to create a tool that makes randomness to any slider for a
> > percentage depending on the ranges it is already set to. I obviously know
> > the ranges, but have a huge number of sliders and [knob] objects so it
> > would be painful to try to get them all.
> > Also, if such a method exists, the randomic thing I wanna do could be
> > implemented to any object without having to look at ist propperties.
> >
> > Would appreciate help or leads to workitout.
> >
>
> how about: normalize all slider ranges between 0..1 and transform the
> output to the desired range only afterwards?
>
> i always thought, that the MIDI-based default scaling of sliders and the
> like was a step back, and that being able to specify the range has
> little gain (though of course i use it...)
>
> fgm,asdr
> IOhannes
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk9EnSYACgkQkX2Xpv6ydvS7GwCgpO45m+ngMiU9EHd3lLb5W7Pb
> FM8AoOQuzXgGVNP+jz+88rUKCfkiPfSz
> =NnuF
> -END PGP SIGNATURE-
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

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

[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] C++ for reusable dsp lib - or better use C?

[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] vbap speaker position not correct?

[Jack]

Le 19/02/2012 19:11, Hans-Christoph Steiner a écrit :

If the amp numbers coming out of vbap are correct, then I think the
problem is in your patch ' your speaker setup, or your space.
About speaker position setup, if you send to [vbap] (from vbap) the 
message 'define_loudspeakers 3 -135 0 -45 0 45 0 135 3' you get in the 
console :

error: define-loudspeakers: Not valid 3-D configuration
But it works fine with 'define_loudspeakers 3 -135 0 -45 0 45 0 135 4'.
Do you know why ?
Thanx.
++

Jack



.hc

On Sat, Feb 18, 2012, at 20:16, Christoph Kuhr wrote:

Hi list,

i used the following define_loudspeakers object:

define_loudspeakers 3 -45 0   0 4545 090 45145 0180
45-145 0-90 45

but if i make a horizontal circle trajectory, the sound comes from
strange positions.
its like an inclined ellipse or something...
i also tried ls-triplets and ls-directions messages without effort.

the values at the vbap outputs are correct.

what could be the problem?

regards
Ck

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


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



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

[PD] spinning rope simulation

[umberto torrez]

Hi, i need to record the sound of a rope spinning very fast, i was thinking
that maybe instead of using recordings: how hard would it be simulating
this kind of sound in puredata? maybe somebody already did something like
this or maybe theres a library?

any hint would be appreciated



here is the sound

http://www.zshare.net/audio/9913047058df7102/



Umberto
___
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.

[Hans-Christoph Steiner]

That's great! I wish I could read it.  I love the idea of including the 
interviews and the PdCon report, it shows the multidimensionality of Pd.  Its 
not just software, but the community behind it as well.

To match this release, I think it would be nice to also have a complete 
Japanese translation of the Pd interface. To contribute, create an account on 
transifex and edit the Japanese translation in this webform:
https://www.transifex.net/projects/p/puredata/resource/templatepot/

.hc

On Feb 20, 2012, at 3:38 AM, Seiichiro MATSUMURA wrote:

> Dear list,
> 
> The world first Japanese Pure Data book for sound programming will be
> published from BNN(Bug News Network) Inc. on 23rd Feb. 2012 in Japan.
> The title is "Pd Recipe Book -Sound Programming with Pure Data". This
> book is written for the programming newbies with the step by step type
> tutorials.
> If you know anybody who can read Japanese and hope to jump into the Pd
> world, please recommend this book.
> 
> Web site (Japanese)
> "Pd Recipe Book -Sound Programming with Pure Data"
> http://www.bnn.co.jp/books/title_index/web/pd_recipe_book_pure_data.html#more
> 
> I hope this become the starting point to spread Pd in Japan.
> 
> best wishes,
> 
> Sei Matsumura
> 
> --
> __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> Seiichiro Matsumura, Ph.D.
> 
> Tokyo University of Technology
> School of Design
> Associate Professor
> 
> http://low-tech-ism.com/
> __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> 
> ___
> Pd-announce mailing list
> pd-annou...@iem.at
> http://lists.puredata.info/listinfo/pd-announce
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list







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



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

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

[katja]

On Wed, Feb 22, 2012 at 1:59 PM, august  wrote:

> Hi Katja,
>
> You might want to have a look at a language called Vala:
>
>        https://live.gnome.org/Vala


Thanks for the link, August. Do you happen to use Vala yourself? I'll
definitely take a deeper look into it.

Katja

___
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?

[Hans-Christoph Steiner]

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

> Le 2012-02-21 à 11:12:00, Hans-Christoph Steiner a écrit :
> 
>> If you look at all the fundamental libraries that are ported and used 
>> everywhere, they are written in C.  freetype, ffmpeg, iconv, libjpeg, 
>> libpng, zlib, bzip2, sqlite, libquicktime, gmerlin, etc.  And of course... 
>> Pd :-)
> 
> STL is used in more different programmes than freetype, ffmpeg, libquicktime 
> and gmerlin together, and it's all written in hardcore C++.
> 
> And how many apps use Qt ? That's all C++ as well.
> 
> Boost is a library... no... it's a large collection of C++ libraries... how 
> many programmers use it ? There are 3000 people on the mailing-list, and 
> then, there are other people.
> 
> What does « fundamental » mean ?

Meaning used widely and in many different programming languages.  STL, Qt, and 
Boost are all only used in C++. freetype, ffmpeg, iconv, libjpeg, libpng, zlib, 
bzip2, sqlite, etc. have been used in many many different languages.

.hc




  http://at.or.at/hans/



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

Re: [PD] Tk Zoom

[Hans-Christoph Steiner]

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

> Le 2012-02-20 à 22:51:00, Hans-Christoph Steiner a écrit :
> 
>> Thanks for your email, I always find it interesting to hear people's 
>> perspectives.  I'm happy to see more people getting involved in development, 
>> so that means we can have more things like zooming interfaces. :-)  Tcl/Tk 
>> can do zooming just fine, by the way ;-)
> 
> 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.

.hc



I have the audacity to believe that peoples everywhere can have three meals a 
day for their bodies, education and culture for their minds, and dignity, 
equality and freedom for their spirits.  - Martin Luther King, Jr.



___
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?

[katja]

These questions, distilled from the discussion, reflect my dilemma:

'Why use C for object oriented programming if you have C++?'

'Why use object oriented programming at all, if you have C?'


Pd classes can be done in C very well, if procedures are not too
complicated and not meant to be used in other contexts. But an
independent reusable library will need equivalents for constructor /
destructor, access methods, private procedures and private data. When
writing C, one has to invent an approach for that, or copy an existing
style. It's in any case more tedious than using C++.

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.

The audio analysis lib I'm planning to do will be intended for static
linking. 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. None of it's
API symbols need be exported globally. The problem is sort of
transferred to the application programmer. Pd's API m_pd.h is well
prepared for compilation with g++. You only need not forget to export
the setup symbol as "EXTERN C".

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. Then I'm not even talking
about version incompatibilities, of which I was unaware till Mathieu
mentioned it.

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

Katja

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

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

[Marco Donnarumma]

excellent!
re-posted here:
http://www.thesaddj.com/japanese-pure-data-book-is-out-now/

I was wondering what about Chikashi book?

cheers,
Marco



On Mon, Feb 20, 2012 at 8:38 AM, Seiichiro MATSUMURA
wrote:

> Dear list,
>
> The world first Japanese Pure Data book for sound programming will be
> published from BNN(Bug News Network) Inc. on 23rd Feb. 2012 in Japan.
> The title is "Pd Recipe Book -Sound Programming with Pure Data". This
> book is written for the programming newbies with the step by step type
> tutorials.
> If you know anybody who can read Japanese and hope to jump into the Pd
> world, please recommend this book.
>
> Web site (Japanese)
> "Pd Recipe Book -Sound Programming with Pure Data"
>
> http://www.bnn.co.jp/books/title_index/web/pd_recipe_book_pure_data.html#more
>
> I hope this become the starting point to spread Pd in Japan.
>
> best wishes,
>
> Sei Matsumura
>
> --
> __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
> Seiichiro Matsumura, Ph.D.
>
> Tokyo University of Technology
> School of Design
> Associate Professor
>
> http://low-tech-ism.com/
> __/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/__/
>
> ___
> Pd-announce mailing list
> pd-annou...@iem.at
> http://lists.puredata.info/listinfo/pd-announce
>
>


-- 
Marco Donnarumma
New Media + Sonic Arts Practitioner, Performer, Teacher, Director.
ACE, Sound Design MSc by Research (ongoing)
The University of Edinburgh, UK
~
Portfolio: http://marcodonnarumma.com
Research: http://res.marcodonnarumma.com | http://www.thesaddj.com |
http://www.flxer.net
Director: http://www.liveperformersmeeting.net
___
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?

[august]

> But indeed, C++ ABI complexities make it harder to get a C++ lib
> working always and everywhere. I've come across the MSVC/GNU
> incompatibility, but didn't know about the GNU version conflicts
> mentioned by Mathieu.

Hi Katja,

You might want to have a look at a language called Vala:

https://live.gnome.org/Vala

It's an OOP language ( looks like  C#) that compiles down to OOP C.   That way,
it is ABI compliant with all other C libs.  You can also create a C lib
yourself from it.

It was written with GNOME's GObject in mind,  so anything you write in Vala
would depend on libglib and libgobjectwhich may or may not be what you
want.  However, if you are creating a DSP library, the larger set of utility
features that libglib has to offer might come in handy.

best 

-august.

-- 
http://aug.ment.org
GPG: 0A8D 2BC7 243D 57D0 469D  9736 C557 458F 003E 6952


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