Re: [PD] learning ambisonics - cartesian to polar patch?

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-03-03 23:42, João Pais wrote:
> Hello,
> 
> I wanted to learn how to use ambisonics to use them in my patches.
> So far my attempts have failed, as I didn't find any documentation
> that gave me a good overview on the subjetc. Mainly, what I needed
> was a patch that allowed me to send in cartesian (x,y) coordinates
> of a room, and spacialize the sound in an ambisonic format. Does
> anyone have such a model that I could follow?

ambisonics works in spheric coordinates distance, azimuth and
elevation (that's *not* polar, which uses distance, azimuth, height)
spheric coordinates are given relative to the listener's position
(whereas cartesian coordinates are often given relative to some
abstract point of origin - which may coincide with the listener's
position or not).

so what you basically have to do is:
- - transform the (global) cartesian coordinate system to a
listener-local cartesian system, by subtracting the listener's
position from the sound-source position
- - transform the cartesian system to a spherical system. e.g. using
zexy's [cart2sph]
- - feed the spherical coordinates into an ambisonics encoder (usually
only the azimuth/elevation part, as distance is something not covered
by standard ambisonics)


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

iEYEARECAAYFAlE0TNkACgkQkX2Xpv6ydvSGvACghkU2Fa3Z/9OSKTp5AfOQv54Q
Eu0AoLRUMI1HaiktmwCM6JlUETl7ERN4
=EBB4
-END PGP SIGNATURE-

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

Re: [PD] send .pd_linux files from maxlib?

[IOhannes m zmoelnig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2013-03-03 23:12, João Pais wrote:
> .l_ia64 - 
> http://sourceforge.net/tracker/?func=detail&aid=3606513&group_id=55736&atid=478070

it
> 
seems like what you call the "wrong format" is a "wrong filename"
(the internal binary format is ok).
if this is the case, you can simply rename your .l_ia64 files to
.pd_linux and that's it.

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

iEYEARECAAYFAlE0S08ACgkQkX2Xpv6ydvSXZQCeL6clIm/WfxF5tI0y3FZBXF0H
AUYAoPCQFO6jdfx8Aqh275FaoMJW94ef
=Mc7Z
-END PGP SIGNATURE-

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

Re: [PD] check this out

[Hans-Christoph Steiner]

Yeah, that video illustrates my point well: if you watch the actual gestures
in that youtube video, you can see they are very deliberate and stilted, not
really natural.  I've never seen anyone play air guitar in such a stuff,
abrupt manner.  The promo video, it looks very natural.  That's why they made
a fake video, because while that sensor will work, it will not work anything
like natural motion.

.hc

On 03/01/2013 08:49 PM, Pedro Lopes wrote:
> EMG in action, detecting fingers through ML:
> - http://www.youtube.com/watch?feature=player_embedded&v=6_7BzUED39A#!
> (Scott Saponas, UIST 09)
> 
> On Sat, Mar 2, 2013 at 2:42 AM, Ivica Ico Bukvic  wrote:
> 
>> EMG is potentially capable of this and with adequate filtering techniques
>> there are papers out there that allow for fairly accurate detection of
>> finger motions. More so, the video shows use of very distinct hand
>> positions. In other words, it is not the gesture but hand shape that can be
>> read accurately and interpreted. I suspect it also has a gyro/accelerometer
>> that works in tandem with multiple EMG sensing points…
>>
>> ** **
>>
>> *From:* pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] *On Behalf
>> Of *Hans-Christoph Steiner
>> *Sent:* Friday, March 01, 2013 12:07 PM
>> *To:* Dafydd Hughes
>> *Cc:* pd list; i go bananas
>> *Subject:* Re: [PD] check this out
>>
>> ** **
>>
>> ** **
>>
>> Also looks like that video was entirely faked.  I see no evidence that any
>> of that video footage was actually based on the sensor input.  It probably
>> works decently, but I highly doubt it works as well as the video.
>>
>> ** **
>>
>> .hc
>>
>> ** **
>>
>> On Mar 1, 2013, at 8:49 AM, Dafydd Hughes wrote:
>>
>>
>>
>> 
>>
>> That looks like a lot of fun!
>>
>> ** **
>>
>> On Thu, Feb 28, 2013 at 8:30 PM, i go bananas  wrote:*
>> ***
>>
>> just cos there's no description, i'll add it here:  it's a muscle sensor
>> that can be used for gestural control.
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>> ** **
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>> ** **
>>
>> ___
>> Pd-list@iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
> 
> 

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

Re: [PD] pd-l2ork feedback

[András Murányi]

On Mon, Mar 4, 2013 at 1:39 AM, Ivica Ico Bukvic  wrote:

>  OK, I checked your patch and now I know why this is happening. Allow me
> to explain:
>
> short (tl;dr) version: once mknob is accelerated (which should be only a
> couple of lines of code inside it) this won't be a problem any more
>

That will be cool.


>
> For me it takes approx 3 seconds every time I move the gop window and this
> solely because mknob is not accelerated (this is on an HP dm1z AMD APU
> notebook/netbook).
>

Yes. It takes much longer in the actual patch where i use it. At least i
managed to reproduce the symptom "in vitro",


>
> long version: What's happening is that pd/extended completely redraws gop
> object every time it is moved. What it does not do, is account for its
> location (front vs. back) in respect to other objects when doing this. So,
> for instance if you move a gop that is behind another object, once it has
> been moved, it will appear in front of it which is wrong since that is not
> an accurate reflection where in the gl_list it is located. Hence, next time
> your entire canvas redraws (which happens inside pd/extended at various
> points), suddenly gop will be again behind the other object. Confusing, no?
> Pd-l2ork in an attempt to keep gl_list consistent always ensures that
> objects remain visually stacked on top of each other in the gl_list order
> no matter what operation you do. In this case, because we have one of the
> few remaining gui objects that do not support accelerated displacement (by
> accelerated displacement I mean tagging such object's components in tcl tk
> and then moving all objects tagged with the word "selected" together via a
> single command rather than redrawing everything), pd-l2ork falls back to
> the old pd/extended way of doing things, just like pd/extended do. It does
> this with one notable exception and that is to ensure that the redrawn
> object remains stacked where it should be (in terms of front/back) it also
> redraws the canvas after such a drag because old way of redrawing does not
> account properly for the visual order that pd-l2ork requires. Since your
> patch has literally a ton of objects pertaining to ad presets, this
> takes a while, and hence the slowness. If you, however, put any iemgui
> object instead of mknob inside that gop, the thing will be not only fast,
> but also much faster than regular pd/extended.
>

Yea i know... i need mknob because of its so called "sensibility" option
(see mknob-help.pd).


>
> So, what I can do for the next release is add support for accelerated
> displacement of mknob and you'll be set.
>

Thanks a lot in advance!


>
> Another related issue is the redundant use of hundreds of ad
> abstractions. Pd-l2ork has system-wide preset_hub/preset_node externals
> system which is easy to use, supports use in conjunction with multiple
> instances of the same abstraction (each is treated separately and
> distinctly) as well as many other cool features. Think of it as pd's
> counterpart to Max's pattr_storage. Their implementation is currently
> possible only in pd-l2ork since it ensures that all objects remain in the
> same place in the gl_list (let's call this gl_list consistency) which is
> something that regular pd/extended don't do (as described above). So, long
> story short, if you use preset_node and preset_hub you will need only one
> of those to replace all of your ad abstractions. Pretty nifty? ;-) And
> that in near-term will make your canvas redrawing much faster and
> consequently a non-issue.
>

Those hundreds of subpatches were there for dummy to make the patch big. In
real life, i use less. I am interested, however, in other preset saving
solutions. I wouldn't lock myself into l2ork at the moment (because it's
0.42) but i'll take a look at the preset_hub thing.

Thanks again Ico!

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

Re: [PD] pd-l2ork feedback

[Ivica Ico Bukvic]

OK, I checked your patch and now I know why this is happening. Allow me 
to explain:


short (tl;dr) version: once mknob is accelerated (which should be only a 
couple of lines of code inside it) this won't be a problem any more


For me it takes approx 3 seconds every time I move the gop window and 
this solely because mknob is not accelerated (this is on an HP dm1z AMD 
APU notebook/netbook).


long version: What's happening is that pd/extended completely redraws 
gop object every time it is moved. What it does not do, is account for 
its location (front vs. back) in respect to other objects when doing 
this. So, for instance if you move a gop that is behind another object, 
once it has been moved, it will appear in front of it which is wrong 
since that is not an accurate reflection where in the gl_list it is 
located. Hence, next time your entire canvas redraws (which happens 
inside pd/extended at various points), suddenly gop will be again behind 
the other object. Confusing, no? Pd-l2ork in an attempt to keep gl_list 
consistent always ensures that objects remain visually stacked on top of 
each other in the gl_list order no matter what operation you do. In this 
case, because we have one of the few remaining gui objects that do not 
support accelerated displacement (by accelerated displacement I mean 
tagging such object's components in tcl tk and then moving all objects 
tagged with the word "selected" together via a single command rather 
than redrawing everything), pd-l2ork falls back to the old pd/extended 
way of doing things, just like pd/extended do. It does this with one 
notable exception and that is to ensure that the redrawn object remains 
stacked where it should be (in terms of front/back) it also redraws the 
canvas after such a drag because old way of redrawing does not account 
properly for the visual order that pd-l2ork requires. Since your patch 
has literally a ton of objects pertaining to ad presets, this takes 
a while, and hence the slowness. If you, however, put any iemgui object 
instead of mknob inside that gop, the thing will be not only fast, but 
also much faster than regular pd/extended.


So, what I can do for the next release is add support for accelerated 
displacement of mknob and you'll be set.


Another related issue is the redundant use of hundreds of ad 
abstractions. Pd-l2ork has system-wide preset_hub/preset_node externals 
system which is easy to use, supports use in conjunction with multiple 
instances of the same abstraction (each is treated separately and 
distinctly) as well as many other cool features. Think of it as pd's 
counterpart to Max's pattr_storage. Their implementation is currently 
possible only in pd-l2ork since it ensures that all objects remain in 
the same place in the gl_list (let's call this gl_list consistency) 
which is something that regular pd/extended don't do (as described 
above). So, long story short, if you use preset_node and preset_hub you 
will need only one of those to replace all of your ad abstractions. 
Pretty nifty? ;-) And that in near-term will make your canvas redrawing 
much faster and consequently a non-issue.


HTH

Best wishes,

Ico

On 03/03/2013 03:10 PM, András Murányi wrote:
The original patch has many dependencies, however I've managed to put 
together a patch which is "big" enough to show the symptom but has no 
other dependency than mknob.
Dragging the violet GOP takes quite a few seconds for me, while 
dragging the other GOP with the numberbox is fast. The GUI is 
unresponsive meanwhile.
Another interesting thing is that when you select a large number of 
those [pd presetstore] subpatches and drag them, it really (ok not 
really) takes forever. But the bottleneck is not the same because the 
GUI stays responsive.

Neither happens in pd-extended.

Thanks for taking a look!

András

On Sun, Mar 3, 2013 at 6:47 PM, Ivica Bukvic > wrote:


Can you forward patch(es)? Does the abstraction use any
non-default gui objects?

On Mar 3, 2013 11:34 AM, "András Murányi" mailto:muran...@gmail.com>> wrote:

On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic mailto:i...@vt.edu>> wrote:

[...]

Regarding slow redraw, can you try latest version? I fixed
one major inefficiency.



I've just compiled the latest git and the slowness is still
there. I have the vague impression though, that dragging the
ominous abstraction got faster (2 minutes vs previous 5), but
again, this is just an impression.

András







--
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

___
Pd-list@iem.at mailing list

[PD] learning ambisonics - cartesian to polar patch?

[João Pais]

Hello,

I wanted to learn how to use ambisonics to use them in my patches. So far  
my attempts have failed, as I didn't find any documentation that gave me a  
good overview on the subjetc. Mainly, what I needed was a patch that  
allowed me to send in cartesian (x,y) coordinates of a room, and  
spacialize the sound in an ambisonic format. Does anyone have such a model  
that I could follow?


Best,

jmmmp

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

Re: [PD] completion-plugin in pd-extended

[João Pais]

I have a windows and mac (powerpc) machine in my room, sharing the same  
keyboard and mouse. is that enough for debugging?



On 25/02/13 14:04, Hans-Christoph Steiner wrote:


For something to be included in Pd-extended, it needs to work on all
platforms, and be stable both in terms of bugs and APIs/interface.  I  
would

love to see the completion plugin get to that point.


oh I see..
as I have no access to osx nor windows machines I guess it'll stay in  
the wild on github for some more time then =)


for example the bug reported here[1] is an OS one IIRC (i.e. users need  
to manually update Tcl on osx and it needs some tweaks, etc so it might  
never work out-of-the-box on osx...)


cheers,
y

[1] https://github.com/gusano/completion-plugin/issues/2




--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmp...@googlemail.com | skype: jmmmpjmmmp

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

Re: [PD] send .pd_linux files from maxlib?

[João Pais]

.l_ia64 -  
http://sourceforge.net/tracker/?func=detail&aid=3606513&group_id=55736&atid=478070



On 03/02/2013 03:51 PM, João Pais wrote:

Hi,

the latest version of pd-ext for debian has the externals of maxlib
compiled in the wrong format.


what's the "wrong format"?

fgmasdr
IOhannes

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



--
Friedenstr. 58
10249 Berlin (Deutschland)
Tel +49 30 42020091 | Mob +49 162 6843570
Studio +49 30 69509190
jmmmp...@googlemail.com | skype: jmmmpjmmmp

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

Re: [PD] pd-l2ork feedback

[Ivica Bukvic]

Thanks for the report. mknob is not accelerated,  so you will get
slowdowns, but those should not be any slower than vanilla pd. I will
investigate further to see if I can reproduce that here and if so, find the
source of the problem.
On Mar 3, 2013 3:10 PM, "András Murányi"  wrote:

> The original patch has many dependencies, however I've managed to put
> together a patch which is "big" enough to show the symptom but has no other
> dependency than mknob.
> Dragging the violet GOP takes quite a few seconds for me, while dragging
> the other GOP with the numberbox is fast. The GUI is unresponsive meanwhile.
> Another interesting thing is that when you select a large number of those
> [pd presetstore] subpatches and drag them, it really (ok not really) takes
> forever. But the bottleneck is not the same because the GUI stays
> responsive.
> Neither happens in pd-extended.
>
> Thanks for taking a look!
>
> András
>
> On Sun, Mar 3, 2013 at 6:47 PM, Ivica Bukvic  wrote:
>
>> Can you forward patch(es)? Does the abstraction use any non-default gui
>> objects?
>> On Mar 3, 2013 11:34 AM, "András Murányi"  wrote:
>>
>>> On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic  wrote:
>>>
 [...]

 Regarding slow redraw, can you try latest version? I fixed one major
 inefficiency.


>>> I've just compiled the latest git and the slowness is still there. I
>>> have the vague impression though, that dragging the ominous abstraction got
>>> faster (2 minutes vs previous 5), but again, this is just an impression.
>>>
>>> András
>>>
>>
>
>
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] file format for GEM

[chris clepper]

A laptop drive will probably not play more than two HD ProRes files at
once.  An external Firewire or USB drive might help if half the clips are
on it and the other half on the internal.

Auto can play at any speed forward or backward: try 'rate -1' or 'rate 1.5'
 etc.  That sets the Quicktime clock for playback to that rate.  It's more
efficient to let QT do the tasking internally.

You can select the starting frame of playback using the frame number into
the second inlet.

On Sun, Mar 3, 2013 at 2:34 PM, Stephan Elliot Perez <
dreamoftheshoreofanotherwo...@gmail.com> wrote:

> I am not using the auto message because I often want to play the files
> backwards or only play a certain part of them. Unless there is a variant of
> auto for this?
>
> When I use the patch for a performance it will be on a laptop, which I am
> not certain will have multiple hard drives. Would a solid state drive
> definitely fix my problem? Otherwise, I suppose I will be stuck with a
> lower resolution for the videos.
>
> -Stephan
>
>
> On Sun, Mar 3, 2013 at 7:22 PM, chris clepper  wrote:
>
>> Are you using 'auto 1' to play the files?  That uses Quicktime to
>> determine the current position which is more efficient than sending a frame
>> number.  You may also want to try 'frame 60' into the gemwin with the auto
>> message for smoother looking output.  That basically syncs the render
>> output with the screen and 'auto 1' only loads a new frame at the rate of
>> the file.
>>
>> Those CPU figures seem about right.  The ProRes HQ files are probably
>> much larger on disk than the AIC files, so the extra CPU time might be
>> waiting for the disk.  That might also be why the AIC files spike at
>> certain points because the drive is working more.  Disk speed is an
>> important factor here: I would spread the files over multiple drives if
>> possible. Obviously, SSD is a good option too.
>>
>> Chris
>>
>> On Sun, Mar 3, 2013 at 1:05 PM, Stephan Elliot Perez <
>> dreamoftheshoreofanotherwo...@gmail.com> wrote:
>>
>>> So, I added the -nomidi -noaudio and -nrt commands as instructed by Mr.
>>> Clepper. This seems to help stop lag in Pure Data itself (so cues are
>>> executed punctually) when using HD-files.
>>>However, I then converted my files to 1920 x 1080 at 100% using
>>> the prores 422 (HQ) codec. The CPU load still climbs to into the 80s and
>>> 90s (even over 100 once) with two videos and into the 120s-160s with three.
>>>Oddly, with the Intermediary Codec, the load is sometimes much
>>> lower (in the 50s for two files) but sharply climbs at other moments
>>> (higher than with the pro-res codecs).
>>>
>>> -Stephan
>>>
>>>
>>>
>>> On Sun, Mar 3, 2013 at 10:10 AM, Peter Venus  wrote:
>>>
 Hello!
 i did not know, that you wanted  to playback HD-material.
 with HD material, i notice problems as well, also with the mjpeg codec.

 anyone having experience with fullHD and other codecs?

 under OSX i found, that apples ProRes 422 codec works best for that
 matter. The only thing being, that its comes with final cut.
 right now, i am running a show, where i use mjpeg in 720p resolution
 with no problems for simultaneous playback of 3 videos.

 cheers, peter

 Am 01.03.13 21:39, schrieb Stephan Elliot Perez:

> So, I reduced the resolution of the files from 1920 x 1080 to 800 x 450
> with the Apple Photo -Jpeg codec and now I have no lag.
>
> The loss in quality is of course noticable, but tolerable...
>
> Thanks again for you help,
> Stephan
>
> On Thu, Feb 28, 2013 at 9:13 AM,  wrote:
>
>  Hello!
>>
>> what video codec are you using?
>> in my experience, a big issue when playing back video with gem,
>> comes from the codecs and container, resulting in extreme differences
>> in
>> cpu-load.
>> i found, that mov-container work way better than avi-container, even
>> though
>> the same codec is used and packed in the container.
>> try  converting your videos to a motion-jpeg codec packed in a
>> quicktime-mov.
>> you could use mpeg-streamclip [1] for that purpose on win /mac
>> machines or
>> ffmpeg on linux.
>>
>> [1] http://www.squared5.com/  free tool for video conversion
>>
>> regards, peter
>>
>>   *Gesendet:* Mittwoch, 27. Februar 2013 um 23:55 Uhr
>> *Von:* "Stephan Elliot Perez" > @gmail.com >
>> *An:* "Cyrille Henry" 
>> *Cc:* pd-list@iem.at
>> *Betreff:* Re: [PD] file format for GEM
>>
>>   A more urgent problem: Although the CPU usage stays under 100 (peak
>> is
>> around 84 with three videos overlapping), there is a substantial
>> amount of
>> lag. If I turn off video processing, a command that should be executed
>> after 30 seconds via the cue list is executed punctually. If I turn
>> it on,
>> the command is 11 seconds late.
>>
>> I can attach the patch if you like, bu

Re: [PD] send .pd_linux files from maxlib?

[IOhannes zmölnig]

On 03/02/2013 03:51 PM, João Pais wrote:

Hi,

the latest version of pd-ext for debian has the externals of maxlib
compiled in the wrong format.


what's the "wrong format"?

fgmasdr
IOhannes

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

Re: [PD] file format for GEM

[chris clepper]

Are you using 'auto 1' to play the files?  That uses Quicktime to determine
the current position which is more efficient than sending a frame number.
 You may also want to try 'frame 60' into the gemwin with the auto message
for smoother looking output.  That basically syncs the render output with
the screen and 'auto 1' only loads a new frame at the rate of the file.

Those CPU figures seem about right.  The ProRes HQ files are probably much
larger on disk than the AIC files, so the extra CPU time might be waiting
for the disk.  That might also be why the AIC files spike at certain points
because the drive is working more.  Disk speed is an important factor here:
I would spread the files over multiple drives if possible. Obviously, SSD
is a good option too.

Chris

On Sun, Mar 3, 2013 at 1:05 PM, Stephan Elliot Perez <
dreamoftheshoreofanotherwo...@gmail.com> wrote:

> So, I added the -nomidi -noaudio and -nrt commands as instructed by Mr.
> Clepper. This seems to help stop lag in Pure Data itself (so cues are
> executed punctually) when using HD-files.
>However, I then converted my files to 1920 x 1080 at 100% using the
> prores 422 (HQ) codec. The CPU load still climbs to into the 80s and 90s
> (even over 100 once) with two videos and into the 120s-160s with three.
>Oddly, with the Intermediary Codec, the load is sometimes much
> lower (in the 50s for two files) but sharply climbs at other moments
> (higher than with the pro-res codecs).
>
> -Stephan
>
>
>
> On Sun, Mar 3, 2013 at 10:10 AM, Peter Venus  wrote:
>
>> Hello!
>> i did not know, that you wanted  to playback HD-material.
>> with HD material, i notice problems as well, also with the mjpeg codec.
>>
>> anyone having experience with fullHD and other codecs?
>>
>> under OSX i found, that apples ProRes 422 codec works best for that
>> matter. The only thing being, that its comes with final cut.
>> right now, i am running a show, where i use mjpeg in 720p resolution with
>> no problems for simultaneous playback of 3 videos.
>>
>> cheers, peter
>>
>> Am 01.03.13 21:39, schrieb Stephan Elliot Perez:
>>
>>> So, I reduced the resolution of the files from 1920 x 1080 to 800 x 450
>>> with the Apple Photo -Jpeg codec and now I have no lag.
>>>
>>> The loss in quality is of course noticable, but tolerable...
>>>
>>> Thanks again for you help,
>>> Stephan
>>>
>>> On Thu, Feb 28, 2013 at 9:13 AM,  wrote:
>>>
>>>  Hello!

 what video codec are you using?
 in my experience, a big issue when playing back video with gem,
 comes from the codecs and container, resulting in extreme differences in
 cpu-load.
 i found, that mov-container work way better than avi-container, even
 though
 the same codec is used and packed in the container.
 try  converting your videos to a motion-jpeg codec packed in a
 quicktime-mov.
 you could use mpeg-streamclip [1] for that purpose on win /mac machines
 or
 ffmpeg on linux.

 [1] http://www.squared5.com/  free tool for video conversion

 regards, peter

   *Gesendet:* Mittwoch, 27. Februar 2013 um 23:55 Uhr
 *Von:* "Stephan Elliot Perez" >>> @gmail.com >
 *An:* "Cyrille Henry" 
 *Cc:* pd-list@iem.at
 *Betreff:* Re: [PD] file format for GEM

   A more urgent problem: Although the CPU usage stays under 100 (peak is
 around 84 with three videos overlapping), there is a substantial amount
 of
 lag. If I turn off video processing, a command that should be executed
 after 30 seconds via the cue list is executed punctually. If I turn it
 on,
 the command is 11 seconds late.

 I can attach the patch if you like, but I probably will not be able to
 send the video clips as one attachment.

 Best regards,
 Stephan


 On Wed, Feb 27, 2013 at 8:19 PM, Stephan Elliot Perez <
 dreamoftheshoreofanotherworld@**gmail.com>
 wrote:

  What is a shader, and how do I use it?
>
>
> On Wed, Feb 27, 2013 at 7:25 PM, Cyrille Henry  wrote:
>
>
>>
>> Le 27/02/2013 19:17, Stephan Elliot Perez a écrit :
>>
>>   Thanks, it works now. For some reason, turning "auto" on and off
>> (with
>>
>>> pix_film) causes the video to lag temporarily, but I do not have this
>>> problem if I use line-objects to go through the frames. The
>>> cpu-usage goes
>>> above 100 if I have more than two videos playing at once, but I
>>> suppose I
>>> don't need more than two for this project...
>>>
>>> Also, what can I do if I want an additive blend instead of a normal
>>> cross-blend?
>>>
>>>
>> i would use a shader for this.
>> it offer great flexibility, even if it's a bit harder to begin with.
>> but that's the way openGL wants you to do now.
>> cheers
>> c
>>
>>
>>
>>> On Tue, Feb 26, 2013 at 10:16 PM, Cyrille Henry >> c...@chnry.net>> wrote:
>>>
>>>  hel

Re: [PD] pd-l2ork feedback

[Ivica Bukvic]

Can you forward patch(es)? Does the abstraction use any non-default gui
objects?
On Mar 3, 2013 11:34 AM, "András Murányi"  wrote:

> On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic  wrote:
>
>> [...]
>>
>> Regarding slow redraw, can you try latest version? I fixed one major
>> inefficiency.
>>
>>
> I've just compiled the latest git and the slowness is still there. I have
> the vague impression though, that dragging the ominous abstraction got
> faster (2 minutes vs previous 5), but again, this is just an impression.
>
> András
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Saving camera dialog

[Alexandros Drymonitis]

With midi or audio you can send Pd a message on load which you get either
with [get-midi-dialog] and [get-audio-dialog] or by connecting [r pd] to
[print], then go to midi/audio settings and press ok. This gives you the
message you have to send so you can use these settings immediately (say, if
you use pd -nogui).
What about using a camera other than the built-in? You can set that by
sending [dialog( to [pix_video], but is it possible to set it by sending Pd
a message? If so, where do you get this message from?
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-l2ork feedback

[András Murányi]

On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic  wrote:

> [...]
>
> Regarding slow redraw, can you try latest version? I fixed one major
> inefficiency.
>
>
I've just compiled the latest git and the slowness is still there. I have
the vague impression though, that dragging the ominous abstraction got
faster (2 minutes vs previous 5), but again, this is just an impression.

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

Re: [PD] Gem:Convert 3d shape(obj) into a string of characters

[Pierre M.]

Hello,
you could also have a look to that :
http://codelab.fr/3862 (in french)

you will find python scripts to export .obj to [GEMglVertex3f] and also
a pyext object to fill vertices in a VBO

p.

Le samedi 02 mars 2013 à 10:42 -0800, ronni montoya a écrit :
> oh cool , but how can i read that text in pd?
> 
> 
> cheers
> 
> R.
> 
> 2013/3/2, Cyrille Henry :
> > hello,
> >
> > a obj file already is coded as text.
> > so you don't have to do any convertion, just open it with a text editor!
> >
> > cheers
> > c
> >
> >
> > Le 02/03/2013 18:06, ronni montoya a écrit :
> >> Hi, i was wondering how can i convert a 3d shape (obj file) into a
> >> string of characters using Gem/pd?
> >>
> >> Is it possible to get a list with all the vertex values of a obj file
> >> using Gem?
> >>
> >> If not, which other options do exist?
> >>
> >>
> >> thanks in advance
> >>
> >> R.
> >>
> >> ___
> >> 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] file format for GEM

[Peter Venus]

Hello!
i did not know, that you wanted  to playback HD-material.
with HD material, i notice problems as well, also with the mjpeg codec.

anyone having experience with fullHD and other codecs?

under OSX i found, that apples ProRes 422 codec works best for that 
matter. The only thing being, that its comes with final cut.
right now, i am running a show, where i use mjpeg in 720p resolution 
with no problems for simultaneous playback of 3 videos.


cheers, peter

Am 01.03.13 21:39, schrieb Stephan Elliot Perez:

So, I reduced the resolution of the files from 1920 x 1080 to 800 x 450
with the Apple Photo -Jpeg codec and now I have no lag.

The loss in quality is of course noticable, but tolerable...

Thanks again for you help,
Stephan

On Thu, Feb 28, 2013 at 9:13 AM,  wrote:


Hello!

what video codec are you using?
in my experience, a big issue when playing back video with gem,
comes from the codecs and container, resulting in extreme differences in
cpu-load.
i found, that mov-container work way better than avi-container, even though
the same codec is used and packed in the container.
try  converting your videos to a motion-jpeg codec packed in a
quicktime-mov.
you could use mpeg-streamclip [1] for that purpose on win /mac machines or
ffmpeg on linux.

[1] http://www.squared5.com/  free tool for video conversion

regards, peter

  *Gesendet:* Mittwoch, 27. Februar 2013 um 23:55 Uhr
*Von:* "Stephan Elliot Perez" 
*An:* "Cyrille Henry" 
*Cc:* pd-list@iem.at
*Betreff:* Re: [PD] file format for GEM
  A more urgent problem: Although the CPU usage stays under 100 (peak is
around 84 with three videos overlapping), there is a substantial amount of
lag. If I turn off video processing, a command that should be executed
after 30 seconds via the cue list is executed punctually. If I turn it on,
the command is 11 seconds late.

I can attach the patch if you like, but I probably will not be able to
send the video clips as one attachment.

Best regards,
Stephan


On Wed, Feb 27, 2013 at 8:19 PM, Stephan Elliot Perez <
dreamoftheshoreofanotherwo...@gmail.com> wrote:


What is a shader, and how do I use it?


On Wed, Feb 27, 2013 at 7:25 PM, Cyrille Henry  wrote:




Le 27/02/2013 19:17, Stephan Elliot Perez a écrit :

  Thanks, it works now. For some reason, turning "auto" on and off (with

pix_film) causes the video to lag temporarily, but I do not have this
problem if I use line-objects to go through the frames. The cpu-usage goes
above 100 if I have more than two videos playing at once, but I suppose I
don't need more than two for this project...

Also, what can I do if I want an additive blend instead of a normal
cross-blend?



i would use a shader for this.
it offer great flexibility, even if it's a bit harder to begin with.
but that's the way openGL wants you to do now.
cheers
c




On Tue, Feb 26, 2013 at 10:16 PM, Cyrille Henry > wrote:

 hello,
 Gem is mostly design to work on the GPU, and not on the CPU.
 GPU have hundreds of core, they are faster than CPU for image
manipulations.

 pix_add come from the 20th century and should now be avoid since it
use cpu not gpu ;-)

 in order to make a fade transition between 2 videos, you can use
transparency on one video.
 add a [alpha] object after Gemhead, and send number between 0 and 1
in the last inlet of the colorRGB object to make the video appear /
disapear.

 cheers
 c


 Le 26/02/2013 21:33, Stephan Elliot Perez a écrit :

 Hello,
  So, looking at the help file for [pd~], it seems to be
primarily for audio. How can I use multiple cores to work purely with GEM?
   I am trying to have a simple transition between video
clips, but if I have two instances of pix_film and then connect them to
pix_add, the CPU-ussage skyrockets well above 100... is there a more
efficient object for blending two video clips?

 Best regards,
 Stephan

 On Sun, Feb 3, 2013 at 10:54 PM, Thomas Mayer <
tho...@residuum.org  mailto:tho...@residuum.org>>> wrote:

  Hi,

  On 03.02.2013 22:48, Stephan Elliot Perez wrote:
   > I am talking about PD's CPU meter. I don't have the
impression that PD
   > takes full advantage of 2 quad-core processors. When
processing audio,
   > anything over 100 in PD's meter will lead to glitched
audio. I am just
   > wondering if it will be much more when I load other
videos and transition
   > between them.

  Pd will only use one core, and one core for the GUI. There
are ways to
  distribute the load over several cores, e.g. [pd~] or use
several
  instances of Pd that communicate with each others:

 
http://www.mail-archive.com/__**pd-list@iem.at/msg33319.html<
http://www.mail-archive.com/**pd-list@iem.at/msg33319.html