Re: [PD] pix_video not working on Mac OS 10.6 ?

[rene beekman]

OK, so it was the 32-bit version I had installed all along.
I downloaded and installed a fresh copy and tried again. The problem persists.
This is when using the pix_video help patch.

Pd window prints this error:
error: [pix_videoDarwin]: SGIdle failed with error -9402
[pix_videoDarwin]: no video yet





On Fri, Sep 30, 2011 at 6:10 PM, Hans-Christoph Steiner  wrote:
>
> As far as I know Pd-extended 0.42.5 32-bit works on Mac OS X 10.6.  The
> 64-bit version does not include Gem.
>
> .hc
>
> On Fri, 2011-09-30 at 09:12 +0300, rene beekman wrote:
>> pd extended 0.42.5
>> Not sure if it was the 64 or the 32-bit version, will have to try that
>> today and report back
>>
>>
>>
>> On Thu, Sep 29, 2011 at 6:24 PM, Hans-Christoph Steiner  
>> wrote:
>> >
>> > Which version of Pd?  It definitely won't work if you downloaded the 64-bit
>> > build.
>> >
>> > .hc
>> >
>> > On Sep 29, 2011, at 2:00 AM, rene beekman wrote:
>> >
>> >> I'm having problems getting pix_video to work with the build-in iSight
>> >> camera on my MacBook. There is no video in the gemwin, just a white
>> >> rectangle.
>> >> When I send it a message to open the control panel, GEM hangs (it
>> >> seems only GEM hangs, I get the beach ball when I hover over the
>> >> GemWin, but can still move and edit the Pd patch)
>> >>
>> >> I've got this on 2 different machines, one 2007 black MacBook and one
>> >> white 2010 machine. Both run 10.6.8 with latest updates applied.
>> >>
>> >> Does anyone else have this problem? Found a solution or even just a
>> >> work-around?
>> >>
>> >> This is coming at the worst of times when tomorrow I need to start
>> >> teaching a motion capture course...
>> >>
>> >> ___
>> >> Pd-list@iem.at mailing list
>> >> UNSUBSCRIBE and account-management ->
>> >> http://lists.puredata.info/listinfo/pd-list
>> >
>> >
>> >
>> > 
>> >
>> > As we enjoy great advantages from inventions of others, we should be glad 
>> > of
>> > an opportunity to serve others by any invention of ours; and this we should
>> > do freely and generously.         - Benjamin Franklin
>> >
>> >
>> >
>
>
>

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

Re: [PD] Fwd: Variable number of objects?

[Ingo]

> If you're going to wire them why not just create specific send messages?
> 
> Give every abstraction an index and send only to that one:
> 
> [r $1-foo]
> |
> etc
> 
> J

Every [receive] will have to check if any [send] message is meant to be for
this particular [receive]. It will have to check if the header of the [send]
matches the header of the [receive] until the first character doesn't match
anymore. Then it will abort checking and the next [receive] will start
checking, and so on ...
I can't see how this can be done without taxing the cpu.

Having several hundred of messages being sent per second going to several
hundred [receives] multiplied by the voice number will add up to many
millions of these checks per second. After a certain amount of objects and
input data this definitely takes too much time for realtime low latency
playing when using high voice counts. It may not affect anything until the
number of [send/receive] exceeds a certain number. Getting rid of the
[send/receive]s at this point takes a ridiculous amount of time (I'm still
not done after several months but getting much better results already).
Using dollar arguments only adds a number to the [receive] and doesn't keep
it from having to do the checking.

That's the reason why I try to avoid [send/receive] objects wherever
realtime playing is involved. I still use them, but only for non realtime
editing purposes. But there is still a tendency for audio dropouts.

Ingo


> On Sep 30, 2011, at 4:13 AM, "Ingo"  wrote:
> 
> > I actually do switch off everything possible with a spigot but the
> > [receive]s do still need to check if the [send] message is meant to be
> for
> > them or not. So once you get too many [receive] objects while sending a
> lot
> > it CAN slow down the patch quite a bit. But unfortunately that only
> starts
> > showing up once the patch is so big that it takes forever to replace all
> of
> > the [receive] objects with wired connections.
> >
> > So for now I'm trying to use wires wherever possible to address data
> only to
> > the object that needs the data rather than having ten thousands of
> objects
> > checking hundreds of times per second if the data is meant to be for
> them or
> > not.
> >
> > Ingo
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com]
> >> Gesendet: Freitag, 30. September 2011 05:04
> >> An: Ingo
> >> Cc: Jonathan Wilkes; Pd List
> >> Betreff: Re: [PD] Fwd: Variable number of objects?
> >>
> >> I see...
> >>
> >> What I do is put a spigot right after all receives and the spigot is
> >> controlled by the same messages that control switch~:
> >>
> >> [r foo]
> >> |
> >> [spigot 0]
> >> |
> >> ...
> >>
> >> In this way you'll at least stop using all lines and metros and the
> >> like. I am not entirely sure that having a receive immediately
> >> connected to a [spigot 0] has any computational expense, but if I'm
> >> measuring things correctly they don't. So no need to shut off
> >> receives, just send them to a closed gate
> >>
> >> best,
> >>
> >> J
> >>
> >> On Thu, Sep 29, 2011 at 10:30 PM, Ingo  wrote:
>  Why would you have control messages going if switch~ is off?
> >>>
> >>> Because the voice gets assigned to a certain midi channel when it
> >> receives a
> >>> [noteon] and has to keep receiving all midi controllers on that
> channel
> >>> until the envelope release has finished. Then the next voice will play
> >> on
> >>> that same midi channel. There is nothing that cuts off the control
> >> inlets or
> >>> [send/receive]s automatically because the audio gets switched off.
> >>> So when you play 16 notes in a row all 16 voices are set up to receive
> >>> control data on that particular midi channel. Everything in the
> control
> >>> domain, like LFOs, [metro]s and [line]s keep running and keep
> >> calculating
> >>> pitch, volume, filter offsets and so on ...
> >>>
> >>> Turning off the [receive]s would be very complicated if not impossible
> >> which
> >>> is why they need to be avoided wherever it can be done. But all of the
> >> wired
> >>> inlets can be cut off manually together with the [switch~] and turned
> >> back
> >>> on when the next note will play that voice. On top of it all 500
> >> parameters
> >>> need to be updated to the current state of the external control input
> >> and
> >>> the current preset data when played anew.
> >>>
> >>> Ingo
> >>>
> >>>
>  -Ursprüngliche Nachricht-
>  Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com]
>  Gesendet: Donnerstag, 29. September 2011 19:56
>  An: Ingo
>  Cc: Jonathan Wilkes; Pd List
>  Betreff: Re: [PD] Fwd: Variable number of objects?
> 
>  On Thu, Sep 29, 2011 at 1:41 PM, Ingo  wrote:
> > One shouldn't underestimate the cpu load when several hundreds of
> >> midi
> > controllers per second are modulating hundreds of parameters and the
> >> get
> > multiplied by 16 voices constantly because the control messages are
> >

Re: [PD] Fwd: Variable number of objects?

[Ingo]

> I wonder what kind of ears it takes to listen to something so complex...
> rather, what kind of brain lobes it takes.

It takes a regular pair of ears - one on the left side and one on the right
side!

Ingo


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

Re: [PD] Fwd: Variable number of objects?

[Mathieu Bouchard]

Le 2011-09-30 à 12:32:00, Jaime Oliver a écrit :


If you're going to wire them why not just create specific send messages?


Yes, that's much faster.

But keep in mind that making large amounts of symbols makes gensym become 
gradually slower, which slows down interpreting $1-foo in all 
messageboxes, for example. The problem appears gradually as you have 
several thousand symbols at once, but I have not benchmarked to see how 
much it changes the balance of things. I think that send/receive will be 
almost always faster than anything else.


[route] is of intermediate speed, faster than [spigot] by a constant ratio 
for an average of many different lookups. [route] is faster than [spigot] 
for high indices (right-side outlets), and even faster for lower indices 
(left-side outlets). [s]/[r] is fast like one of the smallest indices of 
[route].


 __
| 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] Fwd: Variable number of objects?

[Jaime Oliver]

If you're going to wire them why not just create specific send messages? 

Give every abstraction an index and send only to that one:

[r $1-foo]
|
etc

J

On Sep 30, 2011, at 4:13 AM, "Ingo"  wrote:

> I actually do switch off everything possible with a spigot but the
> [receive]s do still need to check if the [send] message is meant to be for
> them or not. So once you get too many [receive] objects while sending a lot
> it CAN slow down the patch quite a bit. But unfortunately that only starts
> showing up once the patch is so big that it takes forever to replace all of
> the [receive] objects with wired connections.
> 
> So for now I'm trying to use wires wherever possible to address data only to
> the object that needs the data rather than having ten thousands of objects
> checking hundreds of times per second if the data is meant to be for them or
> not.
> 
> Ingo
> 
> 
>> -Ursprüngliche Nachricht-
>> Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com]
>> Gesendet: Freitag, 30. September 2011 05:04
>> An: Ingo
>> Cc: Jonathan Wilkes; Pd List
>> Betreff: Re: [PD] Fwd: Variable number of objects?
>> 
>> I see...
>> 
>> What I do is put a spigot right after all receives and the spigot is
>> controlled by the same messages that control switch~:
>> 
>> [r foo]
>> |
>> [spigot 0]
>> |
>> ...
>> 
>> In this way you'll at least stop using all lines and metros and the
>> like. I am not entirely sure that having a receive immediately
>> connected to a [spigot 0] has any computational expense, but if I'm
>> measuring things correctly they don't. So no need to shut off
>> receives, just send them to a closed gate
>> 
>> best,
>> 
>> J
>> 
>> On Thu, Sep 29, 2011 at 10:30 PM, Ingo  wrote:
 Why would you have control messages going if switch~ is off?
>>> 
>>> Because the voice gets assigned to a certain midi channel when it
>> receives a
>>> [noteon] and has to keep receiving all midi controllers on that channel
>>> until the envelope release has finished. Then the next voice will play
>> on
>>> that same midi channel. There is nothing that cuts off the control
>> inlets or
>>> [send/receive]s automatically because the audio gets switched off.
>>> So when you play 16 notes in a row all 16 voices are set up to receive
>>> control data on that particular midi channel. Everything in the control
>>> domain, like LFOs, [metro]s and [line]s keep running and keep
>> calculating
>>> pitch, volume, filter offsets and so on ...
>>> 
>>> Turning off the [receive]s would be very complicated if not impossible
>> which
>>> is why they need to be avoided wherever it can be done. But all of the
>> wired
>>> inlets can be cut off manually together with the [switch~] and turned
>> back
>>> on when the next note will play that voice. On top of it all 500
>> parameters
>>> need to be updated to the current state of the external control input
>> and
>>> the current preset data when played anew.
>>> 
>>> Ingo
>>> 
>>> 
 -Ursprüngliche Nachricht-
 Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com]
 Gesendet: Donnerstag, 29. September 2011 19:56
 An: Ingo
 Cc: Jonathan Wilkes; Pd List
 Betreff: Re: [PD] Fwd: Variable number of objects?
 
 On Thu, Sep 29, 2011 at 1:41 PM, Ingo  wrote:
> One shouldn't underestimate the cpu load when several hundreds of
>> midi
> controllers per second are modulating hundreds of parameters and the
>> get
> multiplied by 16 voices constantly because the control messages are
 still
> active all of the time.
 
 Why would you have control messages going if switch~ is off?
 
 J
 
 
> 
> Ingo
> 
> 
>> - Original Message -
>>> From: Ingo 
>>> To: 'Roman Haefeli' ; 'Ludwig Maes'
>> 
>>> Cc: 'Pd List' 
>>> Sent: Thursday, September 29, 2011 5:33 AM
>>> Subject: Re: [PD] Fwd:  Variable number of objects?
>>> 
>>> Actually, I just tried again to simply copy a couple of voices and
>> it
>> only
>>> took a fraction of a second with a very short dropout - even with
>> the
>> dsp
>>> on.
>>> 
>>> I have recently installed Natty instead of Lucid on a new machine.
 Maybe
>> it
>>> has something to do with realloc that Mathieu mentioned.
>>> 
>>> So it looks like dynamic patching of voices isn't "that" much of a
>>> problem
>>> here anymore. It still takes 7-8 seconds to create 16 voices in my
 case
>> with
>>> the dsp off (12 with the dsp on) but that's still faster than
 restarting
>> the
>>> patch. I would never have checked again if nobody would have
 mentioned
>> it.
>>> 
>>> I have attached a patch that I used for testing. These voices were
>> receiving
>>> their input with [receive] so no connections were needed. If you
>> are
>> using
>>> wired inlets you will have to dynamically add the connections of
 course.
>>> 
>>> I added a cut & paste a

Re: [PD] Re : sigmund~

[Mathieu Bouchard]

Le 2011-09-30 à 08:41:00, Benoît Fortier a écrit :

scale used to calculate waveform. I do understand the whole idea of 
linearity and non-linearity but I guess my confusion come from that I 
tend to see linearity in a relative way.


Yes, linearity is relative, and it can be confusing. But usually, the one 
called linear is the amplitude ; the square of it is called quadratic ; 
and the log of it is called logarithmic.


If you have a logarithmic scale and call it amplitude, both the linear and 
quadratic scales have to be renamed to exponential scale, as do all other 
power scales. Then you can't distinguish them by name anymore, unless you 
start stating the base. This scheme is self-consistent but not used in 
practice.


C'est tout.

 __
| 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] Fwd: Variable number of objects?

[Mathieu Bouchard]

Le 2011-09-30 à 12:01:00, Mathieu Bouchard a écrit :


size_t real_size (size_t n) {return 1<

erratum :

size_t real_size (size_t n) {return 2 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: Variable number of objects?

[Mathieu Bouchard]

Le 2011-09-29 à 19:41:00, Ingo a écrit :

One shouldn't underestimate the cpu load when several hundreds of midi 
controllers per second are modulating hundreds of parameters and the get 
multiplied by 16 voices constantly because the control messages are 
still active all of the time.


I wonder what kind of ears it takes to listen to something so complex... 
rather, what kind of brain lobes it takes.


 __
| 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] Fwd: Variable number of objects?

[Mathieu Bouchard]

Le 2011-09-29 à 10:17:00, Jonathan Wilkes a écrit :

Since you have a large patch, I'd be curious to know how much memory is 
taken up by having the switched off voices just sitting there.


It's not easy to know how much memory is taken by a bunch of small 
mallocs. If you use getbytes() you have some idea of what's going on, but 
it doesn't count the malloc accounting info that only malloc()/free() 
usually know about, and it doesn't count the overallocation that malloc() 
might do in order to make its life easier and make gradual realloc() 
faster. Then it also doesn't count the overallocation of the memory zones 
so that brk() or mmap() or mremap() doesn't have to be called as often, 
which means that when you look at the process size in a process monitor 
(ps or top or other) the difference you might see will not be accurate at 
all... even if you manage to get it in bytes 4k-blocks instead of 
megabytes.


So, if you really want to know the memory usage for a certain part of pd, 
make sure that everything uses getbytes() instead of malloc()/new/etc, and 
then try to find a formula that can tell you how much extra you should 
count, and call it from getbytes() and freebytes() in order to keep 
accurate statistics.


E.g. I recall that will the Perl Allocator that was being used by Perl in 
the late 90's, you had to add sizeof(void*) to your byte request, and then 
round to the next power of two. From this info you can then write :


size_t real_size (size_t n) {return 1>N)&(((typeof(x))1<>=N; i+=N; }
static int highest_bit(uint32 x) {int i=0; Z(16)Z(8)Z(4)Z(2)Z(1)return i;}
#undef Z

 __
| 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-float: rounnding to 1024 points

[tim vets]

sorry, I was a bit too quick, it seems to be because I used
[; wave sinesum 1027 ( instead of [; wave sinesum 1024 (
Wrong assumption on my part, based on the table having to be
"a power of 2 plus three" for sinesum to work...
gr,
Tim


2011/9/30 tim vets 

> Hello,
> why do I get "pd-float: rounnding to 1024 points" ?
> (yes, "rounnding" with 2 n's)
> gr,
> Tim
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] pd-float: rounnding to 1024 points

[tim vets]

Hello,
why do I get "pd-float: rounnding to 1024 points" ?
(yes, "rounnding" with 2 n's)
gr,
Tim
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Re : sigmund~

[Benoît Fortier]

Thanks Frank and Michael.

So I understand that linearity 
of amplitudes in this case and, i guess in many other case as far as pd 
is concerned, refers to the -1 to 1 scale used to calculate waveform. I do 
understand the whole idea of linearity and non-linearity but I guess my 
confusion come from that I tend to see linearity in a relative way. For 
example, one could say that a linear increase in decidel does not correspond to 
a linear increase of peak amplitude, and vice et versa (of course). None of the 
two correspond to a "linear" increase of the sound that we ear either(as in 
twice the value = twice the volume).I'll go have a look at all the readings you 
suggested to me, thanks you again for that. I do remember I've read something 
about it in Miller's book.


Is there anyone else out there using pd to make tools for composers? stuff like 
spectral analysis that outputs notes in midi format, or tools that transform 
and modulate melodic patterns in various ways, and then output the result in 
midi?


Thanks again!
Benoît




De : Frank Barknecht 
À : pd-list@iem.at
Envoyé le : Vendredi 30 Septembre 2011 3h44
Objet : Re: [PD] sigmund~

Hi,

On Thu, Sep 29, 2011 at 06:35:51PM -0700, Benoît Fortier wrote:
> I'm using the sigmund~ object to get amplitude and pitch information
> for the loudest peaks of a signal (see the sinusoid-tracking help
> patch, which can be found in the sigmund~ help patch). Out of that
> information, I want to create, let's say, 5 midi notes corresponding
> to the 5 loudest peaks of the signal. How would you transform the peak
> amplitude outputs of sigmund, which are linear, into midi velocities
> in order to make those 5 notes sound with the same relative amplitude
> that they have in the analysed signal?
> 
> It might be a stupid question but what are those linear peak amplitude
> values exactly? Do they have any unit?

They don't have a "unit", they specify the actual peak amplitude of a
sine component in a signal. If you feed a sigmund~ with an unscaled
[osc~] the peak reported should be close to 1, as the sinewave coming
out of an [osc~] goes from -1 to 1, so the absolute peak is 1. If you
attenuate this [osc~] by multiplying it by 0.5, sigmund~ should report a
peak near 0.5 accordingly. The amplitude is "linear" in that it directly
outputs this multiplication factor - multiplication by constants
("homogeneity of degree 1") and addition ("additivity") are the two
"linear" operations here. See e.g.
http://en.wikipedia.org/wiki/Linear_map for some gory details.

There also are non-linear operations possible. For example
multiplication of a signal with itself is a first step into the
non-linear world. You may remember the parabolic curve if you plot
f(x)=x*x which looks like a glass of wine and obviously is not a
straight line(ar) anymore.  dB-curves are similarily skewed, as are
square root, log, or other [pow] curves. 

Now it's possible to express the amplitude of signals in various ways.
The peak amplitude above actually already is a modification in that it
only considers the absolute value of the actual amplitude (which is
negative sometimes in the case of an [osc~], but not for a [phasor~]!).

You could also look at the instantaneous amplitude of a signal with
[snapshot~] for example, or calculate some kind of average, or use the
absolute peak-to-peak-amplitude (which would be 2 for an [osc~]!)

A very important amplitude specification is the RMS or root-mean-square
amplitude. This is especially interesting as a signal's power is
proportional to the square of RMS. RMS in Pd is calulated by the [env~]
object.

Now in music you very often are interested in powers, intensities
or loudness (more complicated) values, for example you want something to
be twice as loud as another sound. That's where logarithms and decibels
come in. Check e.g. this
http://hep.physics.indiana.edu/~rickv/Loudness_Scales.html
for some details.

In Pd an important thing to know is its non-standard use of the term dB:
For example [env~] outputs values in "dB" which are scaled so that a
[sig~ 1] will have an RMS of 100, and [sig~ 0] has RMS of 0. But to
convert these into linear amplitude multipliers from 0 to 1 you cannot
just divide by 100, as your intermediate values would be wrong: [sig~
0.5] gives an [env~] of about 93.97 and not 0.5 as might be expected!
Instead use [dbtorms] here, and [rmstodb] for the undo-operation. The
attached file shows these operations in action.

More reading stuff:
http://en.wikipedia.org/wiki/Amplitude
http://www.iu.edu/~emusic/acoustics/amplitude.htm

Ciao
-- 
Frank

___
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] pix_video not working on Mac OS 10.6 ?

[Hans-Christoph Steiner]

As far as I know Pd-extended 0.42.5 32-bit works on Mac OS X 10.6.  The
64-bit version does not include Gem.

.hc

On Fri, 2011-09-30 at 09:12 +0300, rene beekman wrote:
> pd extended 0.42.5
> Not sure if it was the 64 or the 32-bit version, will have to try that
> today and report back
> 
> 
> 
> On Thu, Sep 29, 2011 at 6:24 PM, Hans-Christoph Steiner  wrote:
> >
> > Which version of Pd?  It definitely won't work if you downloaded the 64-bit
> > build.
> >
> > .hc
> >
> > On Sep 29, 2011, at 2:00 AM, rene beekman wrote:
> >
> >> I'm having problems getting pix_video to work with the build-in iSight
> >> camera on my MacBook. There is no video in the gemwin, just a white
> >> rectangle.
> >> When I send it a message to open the control panel, GEM hangs (it
> >> seems only GEM hangs, I get the beach ball when I hover over the
> >> GemWin, but can still move and edit the Pd patch)
> >>
> >> I've got this on 2 different machines, one 2007 black MacBook and one
> >> white 2010 machine. Both run 10.6.8 with latest updates applied.
> >>
> >> Does anyone else have this problem? Found a solution or even just a
> >> work-around?
> >>
> >> This is coming at the worst of times when tomorrow I need to start
> >> teaching a motion capture course...
> >>
> >> ___
> >> Pd-list@iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
> > 
> >
> > As we enjoy great advantages from inventions of others, we should be glad of
> > an opportunity to serve others by any invention of ours; and this we should
> > do freely and generously. - Benjamin Franklin
> >
> >
> >



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

Re: [PD] PD-Launch videos + Miller Puckette's 20-lecture puredata video course??

[TAD BISAHA]

Hi all,
Thank you for this precision, Miller.
Consequently, Epic and the other interested people, you have the choice 
( that sounds good)

between probing your patience or misusing this link:

http://pd-la.info/2011/04/pd-la-usb-stick/

Au plaisir,
Tad

Miller Puckette a écrit :

Hi all --

There are raw videos (taken by Joe Deken) but they're 30G in total and
there are problems with the sound.  Joe and Theron Trowbridge have ben working
on cleaning them up and compressing them - this turns ou to be a big job.
I'm hoping we'll end up with 20 400-ish-megabyte individual files I can host
on CRCA, but can't yet make any promises about timing :)

Miller

On Tue, Sep 27, 2011 at 09:16:31AM -0500, Epic Jefferson wrote:
  

good, please let us know as soon as the videos are uploaded.


On Sunday, September 25, 2011, TAD BISAHA  wrote:


Hi the List
The answer is described in the attachment.
I transfer the videos on vimeo these next days (not before friday)
I give you the links in end of this week
Au plaisir
Tad

Epic Jefferson a écrit :
  

I think it's more a question of Miller being ok with the videos being


uploaded.


On Sun, Sep 25, 2011 at 11:23 AM, TAD BISAHA 

tadbis...@gmail.com>> wrote:


   Hi the list
   I have the videos (USB stick), I can put them on Vimeo or ftp server.
   But there's a grand question, is everyone of agreement?
   Au plaisir
   Tad

   Darrell Berry a écrit :

   If there's trivial but tedious work to be done on them, why
   not upoad them somewhere as data files and let the community
   do the work? I'm sure many of us would offer some time in
   return for ongoing access to such a resource...?

   Julian Brooks mailto:jbee...@gmail.com>>
   wrote:

  Any real reason why the videos can't go on somewhere like Vimeo
  for example and upload the patches somewhere too?  Seems a
   rather
  awkward process.

  I'm sure lots of people would be interested in checking these
  out.  Particularly if your shipping them 'at cost', why not
   save
  yourself lots of bother.

  I do get the reasoning for doing the usb stick (which look
   great
  btw) but a little more open access would be far greater.

  Cheers,

  Julian`

  2011/9/25 Theron Trowbridge mailto:theron.trowbri...@gmail.com>
  >>


  Hello, all.

  The delay on the videos being posted is entirely my
   fault.  We
  found a
  (really) minor problem with the videos and I need to
   fix all
  of them.

  But the videos from the sticks exist.  The USB sticks
   are sold
  though
  the CRASHspace store, but we don't really do shipping.

  That being said, anyone who is interested in the videos
   should
  e-mail
  me directly (theron.trowbri...@gmail.com
   
  >).  I have shipped out
   copies

  on DVD-R at cost and USB sticks as well.  The shipping
  internationally
  can get a bit pricey, but I've shipped them around the
   world, too.

  I apologize for the delay and any frustration I have
   caused.
   We want
  to get these videos out to everyone.


  -Theron
  ^

  2011/9/24 Richie Cyngler mailto:glitch...@gmail.com>
  >>:

  > As far as I can tell that link is for the lectures on
   a usb
  stick available
  > if you're in LA. For those of us further away they were
  going to go up
  > online. I think Theron was working on this. Any
   updates? I'd
  be very
  > interested in viewing these lectures too.
  >
  > Thanks heaps
  > On Sun, Sep 25, 2011 at 6:37 AM, TAD BISAHA
  mailto:tadbis...@gmail.com>
   >> wrote:
  >>
  >> Bonjour João,
  >> Take a look at this address:
  http://pd-la.info/2011/04/pd-la-usb-stick/
  >> I took this link to acquire a USB.  contents: videos +
  patchs  Videos ok,
  >> some patchs of examples are missing, but it's of your
  level, I believe ;-)
  >> Au plaisir, Tad
  >>
  >> Ps: about PdCon last night in Berlin, did you find some
  cables (4)? jack
  >> 6.35
  >> For the time being, there is only my head which I do not
   

[PD] [PD-announce] Pd-Taipei meeting tomorrow

[red honki]

[image: Pd-Taipei] 


Pd-Taipei 是一群喜愛Puredata
的使用者聚會。這次聚會的發起相當特別，是因為旅居英國的藝術家李駿難得回來台灣而發起的聚會，我們期待這次的開始能夠像其他國家的Pd
使用者聚會，例如加拿大蒙特利爾的Pd-Mtl、德國柏林的Pd-Berlin、美國加州的Pd-La
一樣，慢慢有個穩定週期的小聚，讓老朋友與新朋友一起討論、使用Pd 創作並且享受Hack 所帶來的樂趣。


此聚會沒有任何主題，也未安排課程，主要以自學與交流的方式為主。


想知道最新的討論，請訂閱我們的網上論壇 


時間：2011/10/01 星期六 AM11:00

地點：23Design 
（台北市重慶北路三段25巷3-5號
）


Pd-Taipei is set up by a group of Pure Data users in Taipei, which aims to
host regular gatherings to create a fun place where people can share their
experience and trouble-shoot, just like Pd-Mtl in Montreal of Canada,
Pd-Berlin in Berlin of Germany, Pd-La in the California of the United States
etc.


Sign up today to learn more updates from the link of our online forum

http://groups.google.com/group/openlabtaipei


Gathering Time: 2011/10/01 Saturday AM11: 00

Location: 23Design (Chongqing North Road, Taipei, No. 25, Lane 3--5)
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fwd: Variable number of objects?

[IOhannes m zmölnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/30/2011 05:03 AM, Jaime Oliver wrote:
> I see...
> 
> What I do is put a spigot right after all receives and the spigot is
> controlled by the same messages that control switch~:
> 
> [r foo]
> |
> [spigot 0]
> |
> ...
> 
> In this way you'll at least stop using all lines and metros and the
> like. I am not entirely sure that having a receive immediately
> connected to a [spigot 0] has any computational expense, 

it sure has.

nevertheless, i usually can be neglected, so i would suggest the same to
save some CPU power down the patch.

[line] can be become quite expensive when used massively, and a
switched-off [line~] that is fed with new values can also make problems
(at least it did a while ago; dunno whether this has been fixed)

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

iEYEARECAAYFAk6FqfoACgkQkX2Xpv6ydvRN6wCfXCWQAedpQOf6CPnpgf99enft
jFAAn36dDJYbyTO7ZfIjHYQ40gLqsPB7
=Tu2Z
-END PGP SIGNATURE-

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

[PD] [PD-announce] DEADLINE EXTENDED: Ircam Musical Research Residency 2012-13

[Arshia Cont]

(Apologies for cross-postings, French version below)


Call for Projects 2012-2013: Musical Research Residency Program

Submission Deadline: October 14, 2011 (Midnight Paris Time)
Details and submission procedure:
http://www.ircam.fr/875.html?L=1

The third edition of Ircam's Musical Research Residency program is now  
open for online submissions for the 2012-2013 school calendar. Ircam  
(Institute for Research and Coordination in Acoustics and Music)  
offers experimental environments where composers/artists strive to  
expand their artistic experience at one end, and scientists aim at  
extending research and technological paradigms for new artistic  
expressions. Such interactive process is called Musical Research.



For its third edition, Ircam is inviting composers and artists to  
submit projects for the 2011-2012 Musical Research Residency program.  
The program is open to international artists, regardless of age or  
nationality, who wish to carry experimental research using Ircam's  
facilities and extensive research environment. Submission is online  
only and each project will be evaluated by an international panel of  
experts including researchers, composers, computer musicians and  
artists. Upon nomination, each candidate will be granted a residency  
at Ircam during a specific period (three to six months) and in  
association with a team/project at Ircam. In addition, laureates  
receive an equivalent of 1200 Euros per month to cover expenses in  
France.




Appel à projet 2012-2013: Résidence de Recherche Musicale

Date limite de candidature: 14 Octobre 2011
Plus d'information et procédure de candidature:
http://www.ircam.fr/875.html

L’Ircam (Institut de recherche et coordination acoustique/musique)  
offre un environnement unique pour l’expérimentation, permettant aux  
compositeurs d’étendre leur expérience musicale et de repenser leur  
pratique à travers les concepts et idées liés aux développements des  
nouvelles technologies les plus récentes. Ces technologies sont le  
résultat des défis posés aussi bien par les impulsions artistiques que  
par les nouveaux domaines de recherche explorés par les équipes  
scientifiques. À l’Ircam, ce processus interactif est appelé  
“Recherche musicale”.


La troisième édition du programme de résidences de recherche musicale  
est ouverte aux artistes internationaux, sans condition d’âge ou de  
nationalité, qui souhaitent conduire un projet de recherche musicale  
en bénéficiant des facilités matérielles proposées à l’Ircam et de la  
richesse de son environnement de recherche. Les candidats seront  
choisis selon un processus de sélection faisant appel à l’expertise de  
chercheurs et artistes internationaux. Les lauréats vont bénéficier  
d'une résidence à l’Ircam pour une durée de trois à six mois en lien  
étroit avec les équipes de recherche de l’Ircam. Le candidat recevra  
une indemnité forfaitaire équivalente de 1200 euros par mois pour  
couvrir ses frais pendant sa résidence en France.




Arshia Cont
Musical Research Coordinator,
Ircam - Centre Pompidou.
http://mrc.ircam.fr/



 ___
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

Re: [PD] Fwd: Variable number of objects?

[Ingo]

I actually do switch off everything possible with a spigot but the
[receive]s do still need to check if the [send] message is meant to be for
them or not. So once you get too many [receive] objects while sending a lot
it CAN slow down the patch quite a bit. But unfortunately that only starts
showing up once the patch is so big that it takes forever to replace all of
the [receive] objects with wired connections.

So for now I'm trying to use wires wherever possible to address data only to
the object that needs the data rather than having ten thousands of objects
checking hundreds of times per second if the data is meant to be for them or
not.

Ingo


> -Ursprüngliche Nachricht-
> Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com]
> Gesendet: Freitag, 30. September 2011 05:04
> An: Ingo
> Cc: Jonathan Wilkes; Pd List
> Betreff: Re: [PD] Fwd: Variable number of objects?
> 
> I see...
> 
> What I do is put a spigot right after all receives and the spigot is
> controlled by the same messages that control switch~:
> 
> [r foo]
> |
> [spigot 0]
> |
> ...
> 
> In this way you'll at least stop using all lines and metros and the
> like. I am not entirely sure that having a receive immediately
> connected to a [spigot 0] has any computational expense, but if I'm
> measuring things correctly they don't. So no need to shut off
> receives, just send them to a closed gate
> 
> best,
> 
> J
> 
> On Thu, Sep 29, 2011 at 10:30 PM, Ingo  wrote:
> >> Why would you have control messages going if switch~ is off?
> >
> > Because the voice gets assigned to a certain midi channel when it
> receives a
> > [noteon] and has to keep receiving all midi controllers on that channel
> > until the envelope release has finished. Then the next voice will play
> on
> > that same midi channel. There is nothing that cuts off the control
> inlets or
> > [send/receive]s automatically because the audio gets switched off.
> > So when you play 16 notes in a row all 16 voices are set up to receive
> > control data on that particular midi channel. Everything in the control
> > domain, like LFOs, [metro]s and [line]s keep running and keep
> calculating
> > pitch, volume, filter offsets and so on ...
> >
> > Turning off the [receive]s would be very complicated if not impossible
> which
> > is why they need to be avoided wherever it can be done. But all of the
> wired
> > inlets can be cut off manually together with the [switch~] and turned
> back
> > on when the next note will play that voice. On top of it all 500
> parameters
> > need to be updated to the current state of the external control input
> and
> > the current preset data when played anew.
> >
> > Ingo
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Jaime Oliver [mailto:jaime.oliv...@gmail.com]
> >> Gesendet: Donnerstag, 29. September 2011 19:56
> >> An: Ingo
> >> Cc: Jonathan Wilkes; Pd List
> >> Betreff: Re: [PD] Fwd: Variable number of objects?
> >>
> >> On Thu, Sep 29, 2011 at 1:41 PM, Ingo  wrote:
> >> > One shouldn't underestimate the cpu load when several hundreds of
> midi
> >> > controllers per second are modulating hundreds of parameters and the
> get
> >> > multiplied by 16 voices constantly because the control messages are
> >> still
> >> > active all of the time.
> >>
> >> Why would you have control messages going if switch~ is off?
> >>
> >> J
> >>
> >>
> >> >
> >> > Ingo
> >> >
> >> >
> >> >> - Original Message -
> >> >> > From: Ingo 
> >> >> > To: 'Roman Haefeli' ; 'Ludwig Maes'
> >> >> 
> >> >> > Cc: 'Pd List' 
> >> >> > Sent: Thursday, September 29, 2011 5:33 AM
> >> >> > Subject: Re: [PD] Fwd:  Variable number of objects?
> >> >> >
> >> >> > Actually, I just tried again to simply copy a couple of voices and
> it
> >> >> only
> >> >> > took a fraction of a second with a very short dropout - even with
> the
> >> >> dsp
> >> >> > on.
> >> >> >
> >> >> > I have recently installed Natty instead of Lucid on a new machine.
> >> Maybe
> >> >> it
> >> >> > has something to do with realloc that Mathieu mentioned.
> >> >> >
> >> >> > So it looks like dynamic patching of voices isn't "that" much of a
> >> >> > problem
> >> >> > here anymore. It still takes 7-8 seconds to create 16 voices in my
> >> case
> >> >> with
> >> >> > the dsp off (12 with the dsp on) but that's still faster than
> >> restarting
> >> >> the
> >> >> > patch. I would never have checked again if nobody would have
> >> mentioned
> >> >> it.
> >> >> >
> >> >> > I have attached a patch that I used for testing. These voices were
> >> >> receiving
> >> >> > their input with [receive] so no connections were needed. If you
> are
> >> >> using
> >> >> > wired inlets you will have to dynamically add the connections of
> >> course.
> >> >> >
> >> >> > I added a cut & paste at the end because for some reasons the
> voices
> >> >> > didn't
> >> >> > get initialized correctly. Not sure if this is needed for other
> >> >> > voice-abstractions.
> >> >> >
> >> >> > Ingo
> >> >> >
> >> >> >
> >> >> >>  

Re: [PD] sigmund~

[Frank Barknecht]

Hi,

On Thu, Sep 29, 2011 at 06:35:51PM -0700, Benoît Fortier wrote:
> I'm using the sigmund~ object to get amplitude and pitch information
> for the loudest peaks of a signal (see the sinusoid-tracking help
> patch, which can be found in the sigmund~ help patch). Out of that
> information, I want to create, let's say, 5 midi notes corresponding
> to the 5 loudest peaks of the signal. How would you transform the peak
> amplitude outputs of sigmund, which are linear, into midi velocities
> in order to make those 5 notes sound with the same relative amplitude
> that they have in the analysed signal?
> 
> It might be a stupid question but what are those linear peak amplitude
> values exactly? Do they have any unit?

They don't have a "unit", they specify the actual peak amplitude of a
sine component in a signal. If you feed a sigmund~ with an unscaled
[osc~] the peak reported should be close to 1, as the sinewave coming
out of an [osc~] goes from -1 to 1, so the absolute peak is 1. If you
attenuate this [osc~] by multiplying it by 0.5, sigmund~ should report a
peak near 0.5 accordingly. The amplitude is "linear" in that it directly
outputs this multiplication factor - multiplication by constants
("homogeneity of degree 1") and addition ("additivity") are the two
"linear" operations here. See e.g.
http://en.wikipedia.org/wiki/Linear_map for some gory details.

There also are non-linear operations possible. For example
multiplication of a signal with itself is a first step into the
non-linear world. You may remember the parabolic curve if you plot
f(x)=x*x which looks like a glass of wine and obviously is not a
straight line(ar) anymore.  dB-curves are similarily skewed, as are
square root, log, or other [pow] curves. 

Now it's possible to express the amplitude of signals in various ways.
The peak amplitude above actually already is a modification in that it
only considers the absolute value of the actual amplitude (which is
negative sometimes in the case of an [osc~], but not for a [phasor~]!).

You could also look at the instantaneous amplitude of a signal with
[snapshot~] for example, or calculate some kind of average, or use the
absolute peak-to-peak-amplitude (which would be 2 for an [osc~]!)

A very important amplitude specification is the RMS or root-mean-square
amplitude. This is especially interesting as a signal's power is
proportional to the square of RMS. RMS in Pd is calulated by the [env~]
object.

Now in music you very often are interested in powers, intensities
or loudness (more complicated) values, for example you want something to
be twice as loud as another sound. That's where logarithms and decibels
come in. Check e.g. this
http://hep.physics.indiana.edu/~rickv/Loudness_Scales.html
for some details.

In Pd an important thing to know is its non-standard use of the term dB:
For example [env~] outputs values in "dB" which are scaled so that a
[sig~ 1] will have an RMS of 100, and [sig~ 0] has RMS of 0. But to
convert these into linear amplitude multipliers from 0 to 1 you cannot
just divide by 100, as your intermediate values would be wrong: [sig~
0.5] gives an [env~] of about 93.97 and not 0.5 as might be expected!
Instead use [dbtorms] here, and [rmstodb] for the undo-operation. The
attached file shows these operations in action.

More reading stuff:
http://en.wikipedia.org/wiki/Amplitude
http://www.iu.edu/~emusic/acoustics/amplitude.htm

Ciao
-- 
Frank


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