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

2011-09-29 Thread rene beekman
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] compiling pd vanilla in OS X 10.7 Lion

2011-09-29 Thread Rich E
There is a conditional in the makefile(s): HAVE_MSGFMT = no

but po/Makefile is still trying to call msgfmt.  I think it is because
po/Makefile is still added to AC_CONFIG_FILES, but this is where my
investigation ends and I create a bug report. :)

https://sourceforge.net/tracker/?func=detail&aid=3415638&group_id=55736&atid=478070

Concerning gettext in OS X, I got a big warning when installing with
homebrew that OS X ships with GNU gettext (or BSD, can't remember which),
which is weird since homebrew is pretty modern.



On Tue, Sep 27, 2011 at 2:27 AM, Hans-Christoph Steiner wrote:

>
> Hmm, yes, it seems that Mac OS X does not include gettext, its the same on
> my 10.5 install.  You can use the old build system in src/configure.ac and
> get no translations or install gettext and use the new build system.  I
> suppose we need to add gettext detection to the new build system so it'll
> build without gettext.
>
> .hc
>
>
> On Sep 26, 2011, at 12:53 AM, Rich E wrote:
>
> Hi all,
>
> I compiled pd vanilla (Miller's git repo) in OS X 10.7 Lion yesterday and
> ran into (only) a couple hitches.
>
> It seems gettext is missing and this causes the linking to fail because it
> can't find the msgfmt tool. I got it and compiled pd by doing:
>
> sudo brew install --universal gettext
> sudo ln -s /usr/local/Cellar/gettext/0.18.1.1/bin/msgfmt/usr/local/bin/msgfmt
> ./configure CFLAGS="-arch i386" LDFLAGS="-arch i386"
> make
>
> I don't know much about the gettext tool, but am I wrong in thinking that
> it should surely be there and blame apple for messing up on a very common
> unix package?
>
> Cheers,
> Rich
> ___
> 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] sigmund~

2011-09-29 Thread michael noble
For the second part of your question I guess Miller's book would be a good
place to start, given that it also provides examples in pd.

http://crca.ucsd.edu/~msp/techniques/latest/book-html/

For a more advanced source, though not an online resource, the Musimathics
books look thorough and come highly recommended.

-m

2011/9/30 Benoît Fortier 

> Hello all,
>
> 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?
>
> More generally, can you give me any good reference, preferably online, that
> explain in details the physic and mathematic behind sound amplitude? I
> manage to work many things out by myself but i have to admit that my actual
> understanding of it is a little bit superficial. By the way, I have a good
> background in physic and mathematic so don't hesitate to suggest me more
> advanced readings.
>
> Thank you! I've learned a lot from you already just by reading the list.
>
> Benoît
>
> ___
> 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] Fwd: Variable number of objects?

2011-09-29 Thread Jaime Oliver
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
>> >> >
>> >> >
>> >> >>  -Ursprüngliche Nachricht-
>> >> >>  Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im
>> Auftrag
>> >> von
>> >> >>  Roman Haefeli
>> >> >>  Gesendet: Donnerstag, 29. September 2011 08:36
>> >> >>  An: Ludwig Maes
>> >> >>  Cc: Pd List
>> >> >>  Betreff: Re: [PD] Fwd: Variable number of objects?
>> >> >>
>> >> >>  On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
>> >> >>  >
>> >> >>  >
>> >> >>  > -- Forwarded message --
>> >> >>  > From: Ludwig Maes 
>> >> >>  > Date: 28 September 2011 19:29
>> >> >>  > Subject: Re: [PD] Variable number of objects?
>> >> >>  > To: Ingo 
>> >> >>  >
>> >> >>  >
>> >> >>  > I actually meant more in general, also for non-~ signals (i.e.
>> also
>> >> >>  > control rate .pd patches). I referred to polysynth such that
>> people
>> >> >>  > would see more easily what I meant. Are there really no such
>> >> >>  > primitives? That seems like quite a restriction...
>> >> >>  >
>> >> >>  > How can that take 10 seconds?? I dont see what would cause such a
>> >> huge
>> >> >>  > overhead, i'd expect an increase in computations & memory
>> >> > though (say
>> >> >>  > 

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

2011-09-29 Thread Ingo
> 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
> >> >
> >> >
> >> >>  -Ursprüngliche Nachricht-
> >> >>  Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im
> Auftrag
> >> von
> >> >>  Roman Haefeli
> >> >>  Gesendet: Donnerstag, 29. September 2011 08:36
> >> >>  An: Ludwig Maes
> >> >>  Cc: Pd List
> >> >>  Betreff: Re: [PD] Fwd: Variable number of objects?
> >> >>
> >> >>  On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
> >> >>  >
> >> >>  >
> >> >>  > -- Forwarded message --
> >> >>  > From: Ludwig Maes 
> >> >>  > Date: 28 September 2011 19:29
> >> >>  > Subject: Re: [PD] Variable number of objects?
> >> >>  > To: Ingo 
> >> >>  >
> >> >>  >
> >> >>  > I actually meant more in general, also for non-~ signals (i.e.
> also
> >> >>  > control rate .pd patches). I referred to polysynth such that
> people
> >> >>  > would see more easily what I meant. Are there really no such
> >> >>  > primitives? That seems like quite a restriction...
> >> >>  >
> >> >>  > How can that take 10 seconds?? I dont see what would cause such a
> >> huge
> >> >>  > overhead, i'd expect an increase in computations & memory
> >> > though (say
> >> >>  > from 10 voices to 11: 10% increase in cpu workload & ram
> dedicated
> >> > to
> >> >>  > these voices..., I fail to see what would necessitate a long
> >> >>  > initialization...)
> >> >>  >
> >> >>  > also, how is it done even with the long delays?
> >> >>  >
> >> >>
> >> >>
> >> >>  As I understand it, the whole DSP is recompiled whenever it is
> >> changed.
> >> >>  So, if you have a very large patch (and Ingo seems to be an expert
> in
> >> >>  very large patches) and you create another voice, it's easily
> possible
> >> >>  to eat up quite some time.
> >> >>
> >> >>  Also, it's probably much slower the first time, if the voice
> >> > abstraction
>

Re: [PD] Keyboard shortcuts for "nudge", "done editing"

2011-09-29 Thread Marvin Humphrey
On Thu, Sep 29, 2011 at 10:37:45AM -0700, Jonathan Wilkes wrote:
> Something I was thinking about for the future is a way to model keyboard
> input after the efficiency of 'vi' input.  When in "Edit mode" without yet
> editing the text of an object, one could use "h", "j", "k", and "l" to move
> the bounding box selection around in the patch.  Then bind "/" to duplicate
> ctrl-f, and you have a quick way to get around the entire patch without
> leaving home position.  (Maybe also bind "i" to enter text-editing mode, and
> "a" to enter text editing mode at the end of the object's text.) Then when
> in text editing mode or "Run mode", turn off these bindings.
> 
> The tricky part is figuring out the most efficient way to make/edit
> connections.  There is already "auto-connect" behavior for leftmost xlets--
> there needs to be a way to make a new connection, remove a connection, move
> a connection, and possibly make many-to-many connections like [select 0 1 2
> 3 4] with each outlet going to a new message box.
> 
> DesireData has a way to edit connections with the keyboard but I found it
> takes too many keystrokes.

Perhaps some of those features could be accommodated by having configurable
key bindings for the actions in question.  You don't have to provide default
bindings for all options, either -- just provide hooks, and let the user
create key bindings for the actions they care about.

Ever used Logic Audio?  I was quite fond of its key binding preferences
system when I used it a decade ago.

> > What's left is the basically irrelevant issue of how to insert a newline
> > that's going to be turned into a space later anyway.  My inclination is to
> > supply a patch which simply does not support the insertion of newlines.  If
> > that results in user confusion and support inquiries, a binding for
> >  can be added later.
> 
> That will result in user confusion, because when a message box with 
> semicolons gets instantiated it doesn't automatically get newlines added 
> until you save the patch and reopen it, while object boxes add the newlines 
> after instantiation.  Currently the discrepancy can be hidden by always 
> adding the newlines yourself with enter.

Ah, I see.

Source text:

'eep; op; ork; ah-ah;'

Object after instantiation:

eep;
op;
ork;
ah-ah;

Message after instantiation:

eep; op; ork; ah-ah;

Message after close and reopen:

eep;
op;
ork;
ah-ah;

So people who know this and don't want to close-and-reopen require some way to
enter newlines while editing text.

That seems like a bug worth fixing, but I don't feel strongly about
 one way or another, and if it solves a problem people care
about, fine by me.

Marvin Humphrey


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


[PD] sigmund~

2011-09-29 Thread Benoît Fortier
Hello all,

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?


More generally, can you give me any good reference, preferably online, that 
explain in details the physic and mathematic behind sound amplitude? I manage 
to work many things out by myself but i have to admit that my actual 
understanding of it is a little bit superficial. By the way, I have a good 
background in physic and mathematic so don't hesitate to suggest me more 
advanced readings.

Thank you! I've learned a lot from you already just by reading the list.


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


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

2011-09-29 Thread Jaime Oliver
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
>> >
>> >
>> >>  -Ursprüngliche Nachricht-
>> >>  Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag
>> von
>> >>  Roman Haefeli
>> >>  Gesendet: Donnerstag, 29. September 2011 08:36
>> >>  An: Ludwig Maes
>> >>  Cc: Pd List
>> >>  Betreff: Re: [PD] Fwd: Variable number of objects?
>> >>
>> >>  On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
>> >>  >
>> >>  >
>> >>  > -- Forwarded message --
>> >>  > From: Ludwig Maes 
>> >>  > Date: 28 September 2011 19:29
>> >>  > Subject: Re: [PD] Variable number of objects?
>> >>  > To: Ingo 
>> >>  >
>> >>  >
>> >>  > I actually meant more in general, also for non-~ signals (i.e. also
>> >>  > control rate .pd patches). I referred to polysynth such that people
>> >>  > would see more easily what I meant. Are there really no such
>> >>  > primitives? That seems like quite a restriction...
>> >>  >
>> >>  > How can that take 10 seconds?? I dont see what would cause such a
>> huge
>> >>  > overhead, i'd expect an increase in computations & memory
>> > though (say
>> >>  > from 10 voices to 11: 10% increase in cpu workload & ram dedicated
>> > to
>> >>  > these voices..., I fail to see what would necessitate a long
>> >>  > initialization...)
>> >>  >
>> >>  > also, how is it done even with the long delays?
>> >>  >
>> >>
>> >>
>> >>  As I understand it, the whole DSP is recompiled whenever it is
>> changed.
>> >>  So, if you have a very large patch (and Ingo seems to be an expert in
>> >>  very large patches) and you create another voice, it's easily possible
>> >>  to eat up quite some time.
>> >>
>> >>  Also, it's probably much slower the first time, if the voice
>> > abstraction
>> >>  is built of many other abstractions, which need to be read from disk.
>> >>
>> >>  But I guess you are right about the increase in CPU workload _after_
>> the
>> >>  DSP graph has been recompiled: A switch from 10 two 11 instances is
>> >>  expected to show only an increase of 10% in CPU usage.
>> >>
>> >>  It's been said, that often you can gain quite some time while turning
>> >>  off DSP during dynamic instantiation. But I guess, this makes only a
>> >>  difference when performing several instantiations at the same time.
>> When
>> >>  DSP is on, each cycle would cause a complete DSP graph recompilation,
>> >>  whereas when DSP is off, it's only recompiled once (after turning it
>> on
>> >>  again).
>> >>
>> >>
>> >>
>> >>  Roman
>> >>
>> >>
>> >>
>> >>  ___
>> >>  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
>



-- 
Jaime E Oliver LR

www.jaimeoliver.pe

858 750 0924 (cel)
858 202 1522 (home)

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


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

2011-09-29 Thread Ingo

> What happens if you just have the maximum number of voices you think you'd
> ever need and [switch~] them on and off as needed?
> 
> 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.
> 
> -Jonathan

That's what I am doing anyway. Memory is not an issue. There is obviously no
change in memory by simply switching the voices on or off. After I got most
of the control stuff as well as a large number of the [receive] objects out
of the way the patch doesn't need that much cpu time at all unless the
voices are turned on and playing.

Now that the switched off voices are not hardly doing anything anymore there
is no more need to adjust the voice number as it was the case before I got
rid of a whole bunch of [receive] objects and cut most of the control
messages when the [switch~] object gets turned off. In certain cases I can
limit the voice number with different [poly] objects.

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.

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
> >
> >
> >>  -Ursprüngliche Nachricht-
> >>  Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag
> von
> >>  Roman Haefeli
> >>  Gesendet: Donnerstag, 29. September 2011 08:36
> >>  An: Ludwig Maes
> >>  Cc: Pd List
> >>  Betreff: Re: [PD] Fwd: Variable number of objects?
> >>
> >>  On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
> >>  >
> >>  >
> >>  > -- Forwarded message --
> >>  > From: Ludwig Maes 
> >>  > Date: 28 September 2011 19:29
> >>  > Subject: Re: [PD] Variable number of objects?
> >>  > To: Ingo 
> >>  >
> >>  >
> >>  > I actually meant more in general, also for non-~ signals (i.e. also
> >>  > control rate .pd patches). I referred to polysynth such that people
> >>  > would see more easily what I meant. Are there really no such
> >>  > primitives? That seems like quite a restriction...
> >>  >
> >>  > How can that take 10 seconds?? I dont see what would cause such a
> huge
> >>  > overhead, i'd expect an increase in computations & memory
> > though (say
> >>  > from 10 voices to 11: 10% increase in cpu workload & ram dedicated
> > to
> >>  > these voices..., I fail to see what would necessitate a long
> >>  > initialization...)
> >>  >
> >>  > also, how is it done even with the long delays?
> >>  >
> >>
> >>
> >>  As I understand it, the whole DSP is recompiled whenever it is
> changed.
> >>  So, if you have a very large patch (and Ingo seems to be an expert in
> >>  very large patches) and you create another voice, it's easily possible
> >>  to eat up quite some time.
> >>
> >>  Also, it's probably much slower the first time, if the voice
> > abstraction
> >>  is built of many other abstractions, which need to be read from disk.
> >>
> >>  But I guess you are right about the increase in CPU workload _after_
> the
> >>  DSP graph has been recompiled: A switch from 10 two 11 instances is
> >>  expected to show only an increase of 10% in CPU usage.
> >>
> >>  It's been said, that often you can gain quite some time while turning
> >>  off DSP during dynamic instantiation. But I guess, this makes only a
> >>  difference when performing several instantiations at the same time.
> When
> >>  DSP is on, each cycle would cause a complete DSP graph recompilation,
> >>  whereas when DSP is off, it's only recompiled once (after turning it
> on
> >>  again).
> >>
> >>
> >>
> >>  Roman
> >>
> >>
> >>
> >>  ___
> >>  Pd-list@iem.at 

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

2011-09-29 Thread Jaime Oliver
On Thu, Sep 29, 2011 at 1:17 PM, Jonathan Wilkes  wrote:
> What happens if you just have the maximum number of voices you think you'd 
> ever need and
> [switch~] them on and off as needed?

In my case it takes a bit long to load the patch, but if the voices
are switched off then they don't hurt cpu usage at all.

In Pd this is definitely the way to go unless you don't care about
audio dropouts...

J


> 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.
>
> -Jonathan
>
>
>
> - 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
>>
>>
>>>  -Ursprüngliche Nachricht-
>>>  Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von
>>>  Roman Haefeli
>>>  Gesendet: Donnerstag, 29. September 2011 08:36
>>>  An: Ludwig Maes
>>>  Cc: Pd List
>>>  Betreff: Re: [PD] Fwd: Variable number of objects?
>>>
>>>  On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
>>>  >
>>>  >
>>>  > -- Forwarded message --
>>>  > From: Ludwig Maes 
>>>  > Date: 28 September 2011 19:29
>>>  > Subject: Re: [PD] Variable number of objects?
>>>  > To: Ingo 
>>>  >
>>>  >
>>>  > I actually meant more in general, also for non-~ signals (i.e. also
>>>  > control rate .pd patches). I referred to polysynth such that people
>>>  > would see more easily what I meant. Are there really no such
>>>  > primitives? That seems like quite a restriction...
>>>  >
>>>  > How can that take 10 seconds?? I dont see what would cause such a huge
>>>  > overhead, i'd expect an increase in computations & memory
>> though (say
>>>  > from 10 voices to 11: 10% increase in cpu workload & ram dedicated
>> to
>>>  > these voices..., I fail to see what would necessitate a long
>>>  > initialization...)
>>>  >
>>>  > also, how is it done even with the long delays?
>>>  >
>>>
>>>
>>>  As I understand it, the whole DSP is recompiled whenever it is changed.
>>>  So, if you have a very large patch (and Ingo seems to be an expert in
>>>  very large patches) and you create another voice, it's easily possible
>>>  to eat up quite some time.
>>>
>>>  Also, it's probably much slower the first time, if the voice
>> abstraction
>>>  is built of many other abstractions, which need to be read from disk.
>>>
>>>  But I guess you are right about the increase in CPU workload _after_ the
>>>  DSP graph has been recompiled: A switch from 10 two 11 instances is
>>>  expected to show only an increase of 10% in CPU usage.
>>>
>>>  It's been said, that often you can gain quite some time while turning
>>>  off DSP during dynamic instantiation. But I guess, this makes only a
>>>  difference when performing several instantiations at the same time. When
>>>  DSP is on, each cycle would cause a complete DSP graph recompilation,
>>>  whereas when DSP is off, it's only recompiled once (after turning it on
>>>  again).
>>>
>>>
>>>
>>>  Roman
>>>
>>>
>>>
>>>  ___
>>>  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
>



-- 
Jaime E Oliver LR

www.jaimeoliver.pe

858 750 0924 (cel)
858 202 1522 (home)

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


Re: [PD] Keyboard shortcuts for "nudge", "done editing"

2011-09-29 Thread Jonathan Wilkes




- Original Message -
> From: Marvin Humphrey 
> To: Simon Wise 
> Cc: pd-list@iem.at
> Sent: Thursday, September 29, 2011 11:09 AM
> Subject: Re: [PD] Keyboard shortcuts for "nudge", "done editing"
> 
> On Wed, Sep 28, 2011 at 06:17:08PM +0800, Simon Wise wrote:
>>  typing into a spreadsheet cell is somewhat analogous, and probably a 
>>  fairly common activity ...
> 
> Nice connection!
> 
>>  generally  saves and exits the cell, while to put a newline 
> into a
>>  cell without leaving it is  ... not sure what the 
> OSX
>>  equivalent is, maybe .
> 
> I just checked out the Google Docs spreadsheet behavior.  I assume that it
> mimics the interfaces of other popular spreadsheet programs, though I don't
> know that for sure.
> 
>   *  and  both save and exit the cell.
>   *  and  both insert a 
> newline.
>   *  cancels the change and exists the cell.

Something I was thinking about for the future is a way to model keyboard input 
after the efficiency of 'vi' input.  When in "Edit mode" without yet editing 
the text 
of an object, one could use "h", "j", "k", and "l" to move the bounding box 
selection around in the patch.  Then bind "/" to duplicate ctrl-f, and you have 
a 
quick way to get around the entire patch without leaving home position.  (Maybe 
also bind "i" to enter text-editing mode, and "a" to enter text editing mode 
at the end of the object's text.) Then when in text editing mode or "Run mode", 
turn 
off these bindings.

The tricky part is figuring out the most efficient way to make/edit 
connections.  There is 
already "auto-connect" behavior for leftmost xlets-- there needs to be a way to 
make 
a new connection, remove a connection, move a connection, and possibly make 
many-to-many connections like [select 0 1 2 3 4] with each outlet going to a 
new message 
box.

DesireData has a way to edit connections with the keyboard but I found it takes 
too many 
keystrokes.

-Jonathan

> 
> I haven't seen anyone object to Matthieu's suggested behaviors for 
>  and
> , which are consistent with both behavior and general OS gui 
> conventions,
> so I think we may have achieved consensus there.
> 
> What's left is the basically irrelevant issue of how to insert a newline
> that's going to be turned into a space later anyway.  My inclination is to
> supply a patch which simply does not support the insertion of newlines.  If
> that results in user confusion and support inquiries, a binding for
>  can be added later.

That will result in user confusion, because when a message box with 
semicolons gets instantiated it doesn't automatically get newlines added 
until you save the patch and reopen it, while object boxes add the newlines 
after instantiation.  Currently the discrepancy can be hidden by always 
adding the newlines yourself with enter.

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

2011-09-29 Thread Jonathan Wilkes
What happens if you just have the maximum number of voices you think you'd ever 
need and 

[switch~] them on and off as needed?

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.

-Jonathan



- 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
> 
> 
>>  -Ursprüngliche Nachricht-
>>  Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von
>>  Roman Haefeli
>>  Gesendet: Donnerstag, 29. September 2011 08:36
>>  An: Ludwig Maes
>>  Cc: Pd List
>>  Betreff: Re: [PD] Fwd: Variable number of objects?
>> 
>>  On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
>>  >
>>  >
>>  > -- Forwarded message --
>>  > From: Ludwig Maes 
>>  > Date: 28 September 2011 19:29
>>  > Subject: Re: [PD] Variable number of objects?
>>  > To: Ingo 
>>  >
>>  >
>>  > I actually meant more in general, also for non-~ signals (i.e. also
>>  > control rate .pd patches). I referred to polysynth such that people
>>  > would see more easily what I meant. Are there really no such
>>  > primitives? That seems like quite a restriction...
>>  >
>>  > How can that take 10 seconds?? I dont see what would cause such a huge
>>  > overhead, i'd expect an increase in computations & memory 
> though (say
>>  > from 10 voices to 11: 10% increase in cpu workload & ram dedicated 
> to
>>  > these voices..., I fail to see what would necessitate a long
>>  > initialization...)
>>  >
>>  > also, how is it done even with the long delays?
>>  >
>> 
>> 
>>  As I understand it, the whole DSP is recompiled whenever it is changed.
>>  So, if you have a very large patch (and Ingo seems to be an expert in
>>  very large patches) and you create another voice, it's easily possible
>>  to eat up quite some time.
>> 
>>  Also, it's probably much slower the first time, if the voice 
> abstraction
>>  is built of many other abstractions, which need to be read from disk.
>> 
>>  But I guess you are right about the increase in CPU workload _after_ the
>>  DSP graph has been recompiled: A switch from 10 two 11 instances is
>>  expected to show only an increase of 10% in CPU usage.
>> 
>>  It's been said, that often you can gain quite some time while turning
>>  off DSP during dynamic instantiation. But I guess, this makes only a
>>  difference when performing several instantiations at the same time. When
>>  DSP is on, each cycle would cause a complete DSP graph recompilation,
>>  whereas when DSP is off, it's only recompiled once (after turning it on
>>  again).
>> 
>> 
>> 
>>  Roman
>> 
>> 
>> 
>>  ___
>>  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


Re: [PD] Variable number of objects?

2011-09-29 Thread Thomas Grill


The full conference proceedings are due to be published online any  
time soon.


Ok, good to hear that - my bad conscience is not as bad any more.

The Universal Polyphonic Player infrastructure i showed at a workshop  
at the pdconf would also be a feasible approach.
I actually have finished all the patches, it's only about writing up  
some accompanying text.


gr~~~


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


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

2011-09-29 Thread Ingo
I made some more changes and added some help information to the voice
creation patch so you can simple use a float to add voices and 0 to clear
all voices. There are wired inlets for the voices now. 

Hope it's helpful for anybody!

Ingo

> -Ursprüngliche Nachricht-
> Von: Ingo [mailto:i...@miamiwave.com]
> Gesendet: Donnerstag, 29. September 2011 12:02
> An: 'Ingo'; 'Roman Haefeli'; 'Ludwig Maes'
> Cc: 'Pd List'
> Betreff: AW: [PD] Fwd: Variable number of objects?
> 
> I just added the [; pd dsp 0( when starting to creat voices to speed it up
> and eliminated the 17 voices limit of the patch.
> 
> Maybe it's useful for somebody.
> 
> Ingo
> 
> > -Ursprüngliche Nachricht-
> > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag
> von
> > Ingo
> > Gesendet: Donnerstag, 29. September 2011 11:33
> > An: 'Roman Haefeli'; 'Ludwig Maes'
> > Cc: 'Pd List'
> > Betreff: 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
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag
> > von
> > > Roman Haefeli
> > > Gesendet: Donnerstag, 29. September 2011 08:36
> > > An: Ludwig Maes
> > > Cc: Pd List
> > > Betreff: Re: [PD] Fwd: Variable number of objects?
> > >
> > > On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
> > > >
> > > >
> > > > -- Forwarded message --
> > > > From: Ludwig Maes 
> > > > Date: 28 September 2011 19:29
> > > > Subject: Re: [PD] Variable number of objects?
> > > > To: Ingo 
> > > >
> > > >
> > > > I actually meant more in general, also for non-~ signals (i.e. also
> > > > control rate .pd patches). I referred to polysynth such that people
> > > > would see more easily what I meant. Are there really no such
> > > > primitives? That seems like quite a restriction...
> > > >
> > > > How can that take 10 seconds?? I dont see what would cause such a
> huge
> > > > overhead, i'd expect an increase in computations & memory though
> (say
> > > > from 10 voices to 11: 10% increase in cpu workload & ram dedicated
> to
> > > > these voices..., I fail to see what would necessitate a long
> > > > initialization...)
> > > >
> > > > also, how is it done even with the long delays?
> > > >
> > >
> > >
> > > As I understand it, the whole DSP is recompiled whenever it is
> changed.
> > > So, if you have a very large patch (and Ingo seems to be an expert in
> > > very large patches) and you create another voice, it's easily possible
> > > to eat up quite some time.
> > >
> > > Also, it's probably much slower the first time, if the voice
> abstraction
> > > is built of many other abstractions, which need to be read from disk.
> > >
> > > But I guess you are right about the increase in CPU workload _after_
> the
> > > DSP graph has been recompiled: A switch from 10 two 11 instances is
> > > expected to show only an increase of 10% in CPU usage.
> > >
> > > It's been said, that often you can gain quite some time while turning
> > > off DSP during dynamic instantiation. But I guess, this makes only a
> > > difference when performing several instantiations at the same time.
> When
> > > DSP is on, each cycle would cause a complete DSP graph recompilation,
> > > whereas when DSP is off, it's only recompiled once (after turning it
> on
> > > again).
> > >
> > >
> > >
> > > Roman
> > >
> > >
> > >
> > > ___
> > > Pd-list@iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > > http://lists.puredata.info/listinfo/pd-list
#N canvas 607 0 578 744 10;
#X obj 26 21 inlet;
#N canvas 342 529 257 383 voicecanvas 1;
#X restore 26 58 pd voicecanvas;
#X text 254 559 pos left;
#X text 312 559 pos top;
#X obj 297 623 pack f f f;
#X msg 112 562 selectall;
#X msg 82 562 cut;
#X obj 39 616 s reset_system_delay;
#X obj 240 348 f;
#X obj 272 348 + 1;
#X obj 196 395 sel;
#X obj 220 333 bng 15 250 50

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

2011-09-29 Thread Hans-Christoph Steiner


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 for theatrical use

2011-09-29 Thread Max
Hi, maybe you find some of those projects interesting:
http://www.uni-weimar.de/medien/wiki/GMU:Keeping_Track/assignment_four

is there any video of your organic motion setup?

max

Am 28.09.2011 um 18:54 schrieb Pagano, Patrick:

> 
> Hi
> 
> I will be most likely be giving a workshop class for using pure data in 
> theatrical/Dance performance @ SETC this year
> Some of you might remember last year @ EmillyCarr we demo-ed a 5.1 sound 
> server using pd/pdjimmies/lyon potpourri objects
> Interfacing with 4 marker less motion capture units [oganic motion] over 
> network with OSC [still then deprecated oscx libraries]
> 
> SO I am soliciting working simple patches for OSX/Windows [these are not 
> going to be linux folks per se] that can/could be used in theatrical 
> performance
> Hopefully the cool and usable patches will be given away on a commemorative 
> usb stick [free] for workshop attendees.
> 
> Any ideas or patches would be cool
> 
> I wil be showing people how to trigger cues with cameras, devices and other 
> programs in the intro/how-to part
> Then we will show examples of some pieces that were successful with 
> technology [pure data] patches 
> There may be some isadora in there too.
> 
> Please send me stuff
> 
> cheers~
> 
> pp
> 
> 
> ___
> 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] Keyboard shortcuts for "nudge", "done editing"

2011-09-29 Thread Marvin Humphrey
On Wed, Sep 28, 2011 at 06:17:08PM +0800, Simon Wise wrote:
> typing into a spreadsheet cell is somewhat analogous, and probably a 
> fairly common activity ...

Nice connection!

> generally  saves and exits the cell, while to put a newline into a
> cell without leaving it is  ... not sure what the OSX
> equivalent is, maybe .

I just checked out the Google Docs spreadsheet behavior.  I assume that it
mimics the interfaces of other popular spreadsheet programs, though I don't
know that for sure.

  *  and  both save and exit the cell.
  *  and  both insert a newline.
  *  cancels the change and exists the cell.

I haven't seen anyone object to Matthieu's suggested behaviors for  and
, which are consistent with both behavior and general OS gui conventions,
so I think we may have achieved consensus there.

What's left is the basically irrelevant issue of how to insert a newline
that's going to be turned into a space later anyway.  My inclination is to
supply a patch which simply does not support the insertion of newlines.  If
that results in user confusion and support inquiries, a binding for
 can be added later.

Marvin Humphrey


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


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

2011-09-29 Thread Ingo
I just added the [; pd dsp 0( when starting to creat voices to speed it up
and eliminated the 17 voices limit of the patch.

Maybe it's useful for somebody.

Ingo

> -Ursprüngliche Nachricht-
> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von
> Ingo
> Gesendet: Donnerstag, 29. September 2011 11:33
> An: 'Roman Haefeli'; 'Ludwig Maes'
> Cc: 'Pd List'
> Betreff: 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
> 
> 
> > -Ursprüngliche Nachricht-
> > Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag
> von
> > Roman Haefeli
> > Gesendet: Donnerstag, 29. September 2011 08:36
> > An: Ludwig Maes
> > Cc: Pd List
> > Betreff: Re: [PD] Fwd: Variable number of objects?
> >
> > On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
> > >
> > >
> > > -- Forwarded message --
> > > From: Ludwig Maes 
> > > Date: 28 September 2011 19:29
> > > Subject: Re: [PD] Variable number of objects?
> > > To: Ingo 
> > >
> > >
> > > I actually meant more in general, also for non-~ signals (i.e. also
> > > control rate .pd patches). I referred to polysynth such that people
> > > would see more easily what I meant. Are there really no such
> > > primitives? That seems like quite a restriction...
> > >
> > > How can that take 10 seconds?? I dont see what would cause such a huge
> > > overhead, i'd expect an increase in computations & memory though (say
> > > from 10 voices to 11: 10% increase in cpu workload & ram dedicated to
> > > these voices..., I fail to see what would necessitate a long
> > > initialization...)
> > >
> > > also, how is it done even with the long delays?
> > >
> >
> >
> > As I understand it, the whole DSP is recompiled whenever it is changed.
> > So, if you have a very large patch (and Ingo seems to be an expert in
> > very large patches) and you create another voice, it's easily possible
> > to eat up quite some time.
> >
> > Also, it's probably much slower the first time, if the voice abstraction
> > is built of many other abstractions, which need to be read from disk.
> >
> > But I guess you are right about the increase in CPU workload _after_ the
> > DSP graph has been recompiled: A switch from 10 two 11 instances is
> > expected to show only an increase of 10% in CPU usage.
> >
> > It's been said, that often you can gain quite some time while turning
> > off DSP during dynamic instantiation. But I guess, this makes only a
> > difference when performing several instantiations at the same time. When
> > DSP is on, each cycle would cause a complete DSP graph recompilation,
> > whereas when DSP is off, it's only recompiled once (after turning it on
> > again).
> >
> >
> >
> > Roman
> >
> >
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
#N canvas 609 0 565 681 10;
#X text 193 513 pos left;
#X text 251 513 pos top;
#X obj 244 568 pack f f f;
#X msg 131 554 selectall;
#X msg 101 554 cut;
#X msg 61 554 paste;
#X obj 45 608 s reset_system_delay;
#X obj 260 223 f;
#X obj 292 223 + 1;
#X obj 228 280 sel;
#X obj 244 208 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X msg 228 307 0;
#X obj 160 307 spigot;
#X obj 262 435 t b f f;
#X obj 272 462 * 20;
#X msg 406 372 clear;
#X obj 174 124 f;
#X text 305 513 argument (voice number);
#X text 269 108 set number of voices;
#X obj 308 16 loadbang;
#X obj 238 110 nbx 2 14 1 24 0 1 empty empty empty 0 -8 0 10 -261682
-1 -1 4 256;
#X msg 214 531 30;
#X obj 272 482 + 20;
#N canvas 268 529 331 383 voicecanvas 1;
#X restore 26 18 pd voicecanvas;
#X obj 406 392 s pd-voicecanvas;
#X obj 283 48 bng 15 250 50 0 empty empty add_voices -52 7 1 9 -257985
-1 -1;
#X obj 61 581 s pd-voicecanvas;
#X obj 244 608 s pd-voicecanvas;
#X msg 244 588 obj \$1 \$2 samplevoice \$3;
#X obj 30 507 pipe 100;
#X text 20 279 pipe can be set faster;
#X text 242 623 send to ;
#X ob

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

2011-09-29 Thread Ingo
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


> -Ursprüngliche Nachricht-
> Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von
> Roman Haefeli
> Gesendet: Donnerstag, 29. September 2011 08:36
> An: Ludwig Maes
> Cc: Pd List
> Betreff: Re: [PD] Fwd: Variable number of objects?
> 
> On Wed, 2011-09-28 at 19:29 +0200, Ludwig Maes wrote:
> >
> >
> > -- Forwarded message --
> > From: Ludwig Maes 
> > Date: 28 September 2011 19:29
> > Subject: Re: [PD] Variable number of objects?
> > To: Ingo 
> >
> >
> > I actually meant more in general, also for non-~ signals (i.e. also
> > control rate .pd patches). I referred to polysynth such that people
> > would see more easily what I meant. Are there really no such
> > primitives? That seems like quite a restriction...
> >
> > How can that take 10 seconds?? I dont see what would cause such a huge
> > overhead, i'd expect an increase in computations & memory though (say
> > from 10 voices to 11: 10% increase in cpu workload & ram dedicated to
> > these voices..., I fail to see what would necessitate a long
> > initialization...)
> >
> > also, how is it done even with the long delays?
> >
> 
> 
> As I understand it, the whole DSP is recompiled whenever it is changed.
> So, if you have a very large patch (and Ingo seems to be an expert in
> very large patches) and you create another voice, it's easily possible
> to eat up quite some time.
> 
> Also, it's probably much slower the first time, if the voice abstraction
> is built of many other abstractions, which need to be read from disk.
> 
> But I guess you are right about the increase in CPU workload _after_ the
> DSP graph has been recompiled: A switch from 10 two 11 instances is
> expected to show only an increase of 10% in CPU usage.
> 
> It's been said, that often you can gain quite some time while turning
> off DSP during dynamic instantiation. But I guess, this makes only a
> difference when performing several instantiations at the same time. When
> DSP is on, each cycle would cause a complete DSP graph recompilation,
> whereas when DSP is off, it's only recompiled once (after turning it on
> again).
> 
> 
> 
> Roman
> 
> 
> 
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
#N canvas 609 0 565 676 10;
#X text 193 513 pos left;
#X text 251 513 pos top;
#X obj 244 568 pack f f f;
#X msg 117 554 selectall;
#X msg 87 554 cut;
#X msg 47 554 paste;
#X obj 30 608 s reset_system_delay;
#X obj 262 243 f;
#X obj 294 243 + 1;
#X obj 228 280 sel;
#X obj 246 228 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X msg 228 307 0;
#X obj 160 307 spigot;
#X obj 262 435 t b f f;
#X obj 272 462 * 20;
#X msg 406 372 clear;
#X obj 30 527 t b b b b;
#X obj 193 124 f;
#X text 305 513 argument (voice number);
#X text 277 108 set number of voices;
#X obj 298 16 loadbang;
#X obj 247 110 nbx 2 14 1 24 0 1 empty empty empty 0 -8 0 10 -261682
-1 -1 4 256;
#X msg 214 531 30;
#X obj 272 482 + 20;
#N canvas 268 529 331 383 voicecanvas 1;
#X restore 26 18 pd voicecanvas;
#X obj 406 392 s pd-voicecanvas;
#X obj 273 48 bng 15 250 50 0 empty empty add_voices -52 7 1 9 -257985
-1 -1;
#X obj 47 581 s pd-voicecanvas;
#X obj 244 608 s pd-voicecanvas;
#X msg 244 588 obj \$1 \$2 samplevoice \$3;
#X obj 30 507 pipe 100;
#X text 20 279 pipe can be set faster;
#X text 242 623 send to ;
#X obj 298 63 t b b b;
#X obj 337 244 nbx 2 14 0 16 0 0 empty empty empty 0 -8 0 10 -261682
-1 -1 0 256;
#X obj 262 295 +;
#X obj 289 402 s pd-voicecanvas;
#X msg 289 382 obj 30 10 inlet;
#X obj 262 315 t f f;
#X obj 289 355 t b b;
#X obj 289 335 sel 1;
#X msg 262 201 0;
#X obj 193 144 t b f f;
#X obj 160 280 pipe 100;
#X text 339 333 clear subpatch and create inlet;
#X text 339 343 when starting from 1st voice;
#X msg 443 212 set \$1;
#X obj 346 477 f;
#X text 371 476 set automatic voice offset;
#X obj 406 21 bng 15 250 50 0 empty empty reset 17 7 0 10 -258113 -1
-1;
#X msg 406 39 0;
#

Re: [PD] Variable number of objects?

2011-09-29 Thread abel . jerome
Hi,

I wrote an abstraction, using "pd-messages" to create objects, [index] to store 
their ID, and" mouse cut" method to delete them with an ID :
http://abel.jerome.free.fr/pd/dynamic-patching/patchs/dyn-objects/dynObjects.zip

For more informations, I wrote some lines about dynamic patching here :
http://abel.jerome.free.fr/pd/dynamic-patching/reviews/

+
Jérôme

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


[PD] error with RME Fireface + Mac Mini

2011-09-29 Thread João Pais

Hi list,

a friend who doesn't work usually with Pd is trying out a new system:

Mac Mini (around 2-3 years old)
OS X 10.6.8
pd-extended 0.42.5
RME Fireface UFX

Pd works fine, as long as the input count setting in Pd is set to 16 or  
less, all inputs work. If I set it to 17 or more, all inputs stop working.  
Outputs continue to function, though.


I've told him already to try out a previous + nightly build of Pd. He  
replied

"The old version seems to silently crash after changing audio device to the
Fireface. The new versions don't even manage to start up properly."

Does anyone has a suggestion to give?

Thanks,

João

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


Re: [PD] need advice: i386 or amd64 for a new Debian installation?

2011-09-29 Thread Nicola Pandini

Thanks Lorenzo, it works!
There's only a font-related problem: the font seems to be the right one, 
but has a strange behaviour with the borders of the objects (the pic 
attached explain better what I'm talking about).


Il 26/09/2011 10:56, Lorenzo Sutton ha scritto:

Nicola,

See what other say in general about amd64 vs i386.

As for pd-extended I still have a working .deb for amd64 compiled from 
those instructions which seems to work fine (although yes, the 
compilation still seems to be broken). I'd be happy to share it with 
you if you like.


Lorenzo.

On 25/09/2011 09:59, Nicola Pandini wrote:

Thank you for the infos.
I tried to compile pd-extended for amd64 a couple of weeks ago, but it
seems to be broken (reported by Lorenzo Sutton), so I'm trying to find a
precompiled .deb for wheezy.
I found that only 0.43 has a .deb for wheezy (currently without jack
support).
I tried also to install the 0.42.5 .deb for squeeze in wheezy, but I've
got an issue of fonts.
Does anyone know if there is a 0.42.5 .deb for wheezy?


Il 25/09/2011 04:02, Ricardo Lameiro ha scritto:

If you want to use more than 3Gb of ram, you can use a PAE kernel.
This i386
kernel with a patch for extension of the adressable memory.
No dia 24 de Set de 2011 20:42, "Hans-Christoph Steiner"
escreveu:

If you need to access more than 3GB of RAM in Pd, then use 64-bit. If
you are worried about bugs in 64-bit, use 32-bit. But from what I
hear, Pd-extended on Debian/64-bit is good, but I haven't used it.

.hc

On Sep 24, 2011, at 2:48 PM, Nicola Pandini wrote:


Hi, I'm going to install Debian Wheezy on my laptop.
Which version should I install? i386 or amd64?
I'm asking this because I know of issues with pd-extended on 64bit
systems.

Thank you!

Nicola

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->

http://lists.puredata.info/listinfo/pd-list





 




All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated -John Donne



___
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



--
Nicola Pandini
http://www.cassandraweb.it
http://www.myspace.com/thewhitewhisper
http://www.myspace.com/cassandraweb

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


Re: [PD] need advice: i386 or amd64 for a new Debian installation?

2011-09-29 Thread Nicola Pandini
Thank you Hans, I tried Pd-vanilla and began to do bug report for 
pd-extended.


Il 26/09/2011 16:09, Hans-Christoph Steiner ha scritto:


If Jack support isn't working in the nightly builds, please file a bug 
report (from the Help menu -> report bug).


There are a lot of libs now directly included in Debian, as well as 
Pd-vanilla 0.43.


http://packages.debian.org/search?suite=wheezy&keywords=pd-

.hc

On Sep 25, 2011, at 3:59 AM, Nicola Pandini wrote:


Thank you for the infos.
I tried to compile pd-extended for amd64 a couple of weeks ago, but 
it seems to be broken (reported by Lorenzo Sutton), so I'm trying to 
find a precompiled .deb for wheezy.
I found that only 0.43 has a .deb for wheezy (currently without jack 
support).
I tried also to install the 0.42.5 .deb for squeeze in wheezy, but 
I've got an issue of fonts.

Does anyone know if there is a 0.42.5 .deb for wheezy?


Il 25/09/2011 04:02, Ricardo Lameiro ha scritto:
If you want to use more than 3Gb of ram, you can use a PAE kernel. 
This i386

kernel with a patch for extension of the adressable memory.
No dia 24 de Set de 2011 20:42, "Hans-Christoph Steiner"
escreveu:

If you need to access more than 3GB of RAM in Pd, then use 64-bit. If
you are worried about bugs in 64-bit, use 32-bit. But from what I
hear, Pd-extended on Debian/64-bit is good, but I haven't used it.

.hc

On Sep 24, 2011, at 2:48 PM, Nicola Pandini wrote:


Hi, I'm going to install Debian Wheezy on my laptop.
Which version should I install? i386 or amd64?
I'm asking this because I know of issues with pd-extended on 64bit
systems.

Thank you!

Nicola

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->

http://lists.puredata.info/listinfo/pd-list





 


All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated -John Donne



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->

http://lists.puredata.info/listinfo/pd-list




--
Nicola Pandini
http://www.cassandraweb.it/nicolapandini






 



I have always wished for my computer to be as easy to use as my 
telephone; my wish has come true because I can no longer figure out 
how to use my telephone."  --Bjarne Stroustrup (creator of C++)





--
Nicola Pandini
http://www.cassandraweb.it
http://www.myspace.com/thewhitewhisper
http://www.myspace.com/cassandraweb


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