Re: [PD] Pd FLOSS manual update

[Antonio Roberts]

> I recently had a look at the Pd FLOSS manual (Pd FLOSS) and seems a bit out
> of date. so I was wondering if there's anyone interested in updating and
> expanding it.
I have at times thought about doing this, especially the stuff about
GEM and visuals

> so which Pd version should be used for the manual
And this is why I haven't done it. Since pd-extended ended there
hasn't been a reliable way to install libraries which makes writing
some of the documentation/tutorials difficult.

> I think the first thing would be "building a team" (I mean, see who wanna
> get involved) so that we can start planning (what should be updated,
> changed, added and so on).
I think best thing would be to just do it without waiting for a team
or permission. It's not an official document so do it until someone
edits it :-)

Kind regards,

Antonio



On 27 February 2018 at 21:44, mario buoninfante
 wrote:
> Hi everyone,
>
> I recently had a look at the Pd FLOSS manual (Pd FLOSS) and seems a bit out
> of date. so I was wondering if there's anyone interested in updating and
> expanding it.
>
> the amount of work is quite significant and I think there are some important
> decisions to take, considering that huge changes have been introduced since
> then (no more Pd-extended, so which Pd version should be used for the manual
> - I'd say Vanilla since is the only one that for sure won't stop, but of
> course it's possible to add paragraphs about Pd-L2Ork and Purr Data).
>
> I think the first thing would be "building a team" (I mean, see who wanna
> get involved) so that we can start planning (what should be updated,
> changed, added and so on).
>
>
> cheers,
>
> Mario
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>



-- 

anto...@hellocatfood.com
http://www.hellocatfood.com


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

[PD] [PD-announce] NIME 2018 workshop and demo deadline March 1st

[Ivica Ico Bukvic]

NIME 2018 Call for submissions
Please pardon the cross-posting,

*A friendly reminder that the submission deadline of March 1st, 2018, 
for the NIME 2018 conference workshops and non-paper demos is now less 
than 24 hours away. Additional information is available on the website 
(**NIME2018.ORG ).


* *We sincerely look forward to your submissions. In the meantime, 
should you have any questions, please do not hesitate to contact us.*


*About NIME*


NIME (New Interfaces for Musical Expression) is the premier conference 
in human-machine interfaces and interactions for musical performance. 
NIME is a gathering of researchers, designers, musicians, who come 
together to share knowledge, perform music, and build community through 
research presentations, concerts, installations, and workshops.


On behalf of the 2018 NIME Committee I am pleased to announce that the 
NIME 2018 "Mirrored Resonances" Conference call for submissions is now 
officially open! Co-organized between Virginia Tech and the University 
of Virginia, the conference will take place June 3-6, 2018 in 
Blacksburg, Virginia. We welcome submissions of papers, posters, panels, 
musical performances, installations, demos, and workshops, particularly 
those that may respond to the overarching conference theme of “Mirrored 
Resonances” and its thematic areas in any of the many ways they might be 
interpreted. Likewise, we encourage potential participants to consider 
exploring the unique Virginia Tech facilities, including the Institute 
for Creativity, Arts, and Technology’s Cube with a massive high density 
loudspeaker array. The deadline for the *double-blind peer reviewed 
submissions*, including papers, panels, demo papers, music, and 
installations is January 20th, 2018. Submissions created by January 20th 
will continue to be editable until January 27th when the submission 
process will close. Demos without paper and workshops will be *curated 
*and have an extended submission deadline until March 1st, 2018. In 
addition to the NIME and academic communities, we also invite industry, 
as well as non-academic creatives to consider participating in the 
aforesaid categories. For a complete list of important dates visit the 
Participate  page.


We are excited to announce that the conference will feature four keynote 
artists:


*Onyx Ashanti**
**Benjamin Knapp**
**Ikue Mori**
**Pamela Z*


If interested in sponsorship opportunities please do not hesitate to 
contact us 




On behalf of the entire NIME 2018 Committee, we look forward to 
welcoming you in Virginia next June!


Go to the website 



NIME2018.ORG 
Facebook  
Twitter  
Instagram  
Website 


Moss Arts Center
190 Alumni Mall
Blacksburg, VA 24060
Like 
Tweet 
Share 
Forward 
 



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

Re: [PD] Text projection in real time

[Jack]

Hello João,

Le 28/02/2018 à 19:31, João Pais a écrit :
> Hello list,
> 
> I was looking on the best way to display some texts which will be
> produced/improvised in realtime. These will be acessible either as a
> list, OSC, or on a file.
> 
> I tried gem's 2dtext and [flatgui/entry], but they both don't work that
> well, as some or all of the following aren't possible:

You mean [text2d] for the Gem object... In term of performance, I prefer
to use [text3d]... depending of what you need.

> - centered text
> - some texts are long, so the paragraphs have to break at the end of a word
> - black background, white font - font and size will be chosen later
> - fullscreen on a 2nd screen (to be projected)

Everything here is doable with [text2d]/[text3d].

> 
> I imagine the word sliptting and text centering can be calculated in Pd
> so that Gem displays it correctly, but I'm not sure I'll have the time
> for it. So trying another solution such as coordinating with Processing
> or similar would be an option, in case it's easier to implement.

Centering text is by default with [text2d]/[text3d]. You can change this
with the message "justify".
To cut a sentence after a word when a certain amount of letter is
present is not very difficult using [list fromsymbol], [list prepend
10], [list prepend string]/[list trim] (for text2d]/[text3d]).

You can even change line spacing with the message "linedist" on recent Gem.
++

Jack


> 
> Are there any suggestions on how to tackle this?
> 
> Best,
> 
> jmmmp
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list


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

Re: [PD] Speech recognition on Pure Data

[Dan Wilcox]

Again, not within Pd, but we had some success using the CMU Sphinx 4 Java 
library and Processing for this project:

http://danomatika.com/projects/trust-me 


I'm not sure if a Java app will be too heavy for an embedded board though, but 
I can send along the compiled Processing library wrapper I made for Sphinx 4 if 
you want.

Otherwise you can look into the earlier CMU sphinx implementation, but it 
wasn't quite as god as we need it. The fact of the matter is that speech 
recognition is not very good overall unless you send it off to some giant 
server farm ala Siri or Google, privacy issues notwithstanding.

> Hi,
> 
> I'm planning to work on a project that will use a microphone to query on
> freesound database, and we are planning to use speech recognition to send
> the queries.  We will use pure data installed in a Bella board and
> e-textile sensors to process the sound.
> 
> I'm considering send audio and do the speech recognition in a server using
> the Google API or use Sphynx to do the recognition in Pure data. Does
> anyone here has any experience with this recently and can make a suggestion?
> 
> thanks a lot!
> 
> Best,
> Ariane


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

Re: [PD] Text projection in real time

[Berenger Recoules]

Have you tried ofelia ?  it's pretty new but there are some objects
available for text display and it should be pretty straigthforward with
[ofDrawText] and [ofSetTextMode]

https://github.com/cuinjune/ofxOfelia

It should pretty do-able with processing aswell.

2018-02-28 20:17 GMT+01:00 Christof Ressi :

> for text display the browser is a naturally choice. I once did some
> experiments sending and receiving Pd messages with a minimal websockets
> implementation and it worked fine.
>
> > Gesendet: Mittwoch, 28. Februar 2018 um 19:31 Uhr
> > Von: "João Pais" 
> > An: PD-List 
> > Betreff: [PD] Text projection in real time
> >
> > Hello list,
> >
> > I was looking on the best way to display some texts which will be
> > produced/improvised in realtime. These will be acessible either as a
> list,
> > OSC, or on a file.
> >
> > I tried gem's 2dtext and [flatgui/entry], but they both don't work that
> > well, as some or all of the following aren't possible:
> > - centered text
> > - some texts are long, so the paragraphs have to break at the end of a
> word
> > - black background, white font - font and size will be chosen later
> > - fullscreen on a 2nd screen (to be projected)
> >
> > I imagine the word sliptting and text centering can be calculated in Pd
> so
> > that Gem displays it correctly, but I'm not sure I'll have the time for
> > it. So trying another solution such as coordinating with Processing or
> > similar would be an option, in case it's easier to implement.
> >
> > Are there any suggestions on how to tackle this?
> >
> > Best,
> >
> > jmmmp
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> >
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>



-- 
http://b2renger.github.io/
http://berengerrecoules.wordpress.com/
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Text projection in real time

[Christof Ressi]

for text display the browser is a naturally choice. I once did some experiments 
sending and receiving Pd messages with a minimal websockets implementation and 
it worked fine.

> Gesendet: Mittwoch, 28. Februar 2018 um 19:31 Uhr
> Von: "João Pais" 
> An: PD-List 
> Betreff: [PD] Text projection in real time
>
> Hello list,
> 
> I was looking on the best way to display some texts which will be  
> produced/improvised in realtime. These will be acessible either as a list,  
> OSC, or on a file.
> 
> I tried gem's 2dtext and [flatgui/entry], but they both don't work that  
> well, as some or all of the following aren't possible:
> - centered text
> - some texts are long, so the paragraphs have to break at the end of a word
> - black background, white font - font and size will be chosen later
> - fullscreen on a 2nd screen (to be projected)
> 
> I imagine the word sliptting and text centering can be calculated in Pd so  
> that Gem displays it correctly, but I'm not sure I'll have the time for  
> it. So trying another solution such as coordinating with Processing or  
> similar would be an option, in case it's easier to implement.
> 
> Are there any suggestions on how to tackle this?
> 
> Best,
> 
> jmmmp
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

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

[PD] Text projection in real time

[João Pais]

Hello list,

I was looking on the best way to display some texts which will be  
produced/improvised in realtime. These will be acessible either as a list,  
OSC, or on a file.


I tried gem's 2dtext and [flatgui/entry], but they both don't work that  
well, as some or all of the following aren't possible:

- centered text
- some texts are long, so the paragraphs have to break at the end of a word
- black background, white font - font and size will be chosen later
- fullscreen on a 2nd screen (to be projected)

I imagine the word sliptting and text centering can be calculated in Pd so  
that Gem displays it correctly, but I'm not sure I'll have the time for  
it. So trying another solution such as coordinating with Processing or  
similar would be an option, in case it's easier to implement.


Are there any suggestions on how to tackle this?

Best,

jmmmp

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

Re: [PD] Speech recognition on Pure Data

[Claude Heiland-Allen]

Hi,

On 28/02/18 16:53, Ariane stolfi wrote:
> I'm planning to work on a project that will use a microphone to query on
> freesound database, and we are planning to use speech recognition to
> send the queries.  We will use pure data installed in a Bella board and
> e-textile sensors to process the sound.
> 
> I'm considering send audio and do the speech recognition in a server
> using the Google API or use Sphynx to do the recognition in Pure data.
> Does anyone here has any experience with this recently and can make a
> suggestion?

I used pocket_sphinx from the command line in one project (that didn't
use Pd)[1] The key line for speech transcription in my shell script is:
utterance="$(pocketsphinx_continuous -infile utterance.wav 2>/dev/null)"
The input was synthetic sound, so rather noise-free ideal conditions.

I imagine that you could use Pd to do something like detect presence of
sound and save the segment to a wav file, calling out to Sphinx with a
scripting external.  The same process would be necessary for Google API
I suppose, unless you intend to be streaming everything there.


Claude

[1] https://mathr.co.uk/blog/2017-04-08_divergent_protocol.html
-- 
https://mathr.co.uk

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

[PD] Speech recognition on Pure Data

[Ariane stolfi]

Hi,

I'm planning to work on a project that will use a microphone to query on
freesound database, and we are planning to use speech recognition to send
the queries.  We will use pure data installed in a Bella board and
e-textile sensors to process the sound.

I'm considering send audio and do the speech recognition in a server using
the Google API or use Sphynx to do the recognition in Pure data. Does
anyone here has any experience with this recently and can make a suggestion?

thanks a lot!

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

[PD] Fw: Re: stale pointers after object creation (was Re: pix_data issue)

[Christof Ressi]

OK, I see that the refcount is not per scalar but per glist (in t_gstub) so if 
I understand correctly it's not possible to selectively invalidate gpointers 
only for the deleted scalars.

also I have to correct myself: adding scalars doesn't invalidate pointers.

so the remaining problem is adding/deleting non-scalar objects. do you consider 
this a bug or is this by design? if it's a bug I'll make a PR to fix it.
I attached a simple test case to illustrate the problem.

Christof

> Gesendet: Mittwoch, 28. Februar 2018 um 13:54 Uhr
> Von: "Christof Ressi" 
> An: pd-list 
> Cc: "Miller Puckette" 
> Betreff: Re: [PD] stale pointers after object creation (was Re: pix_data 
> issue)
>
> I noticed this issue ca. one year ago when I started working on a complex 
> project with data structures which involved dynamically adding/deleting 
> objects to/from a canvas. I even submitted a bug report: 
> https://sourceforge.net/p/pure-data/bugs/1282/
> 
> since I've recently started doing a couple a PRs, this is something I want to 
> investigate too.
> 
> to explain the problem quickly:
> 
> a glist (list of graphical objects) is internally implemented as a linked 
> list. usually, a big advantage of a linked lists is that adding/deleting 
> elements won't touch other elements (especially doesn't move them in memory, 
> like it can happen with dynamically sized arrays). I don't see why 
> adding/deleting graphical objects should invalidate any gpointers - apart 
> from those which pointed to the deleted element(s).
> 
> I guess it's meant as a means to keep Pd pointers safe - but what situation 
> does it try it prevent?
> and why are gpointers also invalidated if you add/delete "normal" text 
> objects which are not scalars (and so no gpointer could possibly point to it)?
> 
> any pointers (no pun intended) to the reasons behind this desigin decision 
> are highly appreciated :-)
> 
> 
> 
> > Gesendet: Mittwoch, 28. Februar 2018 um 12:17 Uhr
> > Von: Fede 
> > An: pd-list@lists.iem.at
> > Betreff: [PD] stale pointers after object creation (was Re: pix_data issue)
> >
> > Ok, so it is a combination of editing the canvas and pointer memory
> > 
> > i don’t think it has to do with saving.
> > also, i don’t think it would relate to the previous pix_data pointer issue
> > 
> > Here’s a patch
> > 
> > 
> > 
> > On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig  wrote:
> > 
> > > On 02/28/2018 10:53 AM, Fede Camara Halac wrote:
> > >> Would saving (cmd+s) make pix_data forget a pointer, as in [text] or 
> > >> [array] objects when using pointers?
> > > 
> > > that sounds very fishy to.
> > > do you have a patch that exposes the forget-on-save behaviour of [array]
> > > or [text]?
> > > 
> > > gfmdasr
> > > IOhannes
> > > 
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management -> 
> > > https://lists.puredata.info/listinfo/pd-list
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> >
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

gpointer-issue.pd
Description: Binary data
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] stale pointers after object creation (was Re: pix_data issue)

[Jonathan Wilkes via Pd-list]

> a glist (list of graphical objects) is internally implemented as a linked 
> list. usually, a big 

> advantage of a linked lists is that adding/deleting elements won't touch 
> other elements 

> (especially doesn't move them in memory, like it can happen with dynamically 
> sized arrays).

That's the theory.

In practice the insidious audio dropouts happen when Pd is 

*iterating* over a glist, not when adding/deleting objects.

This is because users learn relatively quickly the simple rule 

that adding/deleting objects rebuilds the signal graph, so they 

avoid doing that if at all possible during performance.

However, users generally have no idea what triggers a walk through 

the glist linked list. And those trips can easily cause dropouts 

during a performance-- even merely moving the mouse over a canvas.

So in practice, glist as linked list optimizes for the case not 

often used in realtime performance and is a detriment to performance 

in the cases where it matters (esp. compared to iterating over an 

array, though the number of glist iterations with things like 

mouse motion might trip up audio anyway).

-Jonathan

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

Re: [PD] stale pointers after object creation (was Re: pix_data issue)

[Christof Ressi]

I noticed this issue ca. one year ago when I started working on a complex 
project with data structures which involved dynamically adding/deleting objects 
to/from a canvas. I even submitted a bug report: 
https://sourceforge.net/p/pure-data/bugs/1282/

since I've recently started doing a couple a PRs, this is something I want to 
investigate too.

to explain the problem quickly:

a glist (list of graphical objects) is internally implemented as a linked list. 
usually, a big advantage of a linked lists is that adding/deleting elements 
won't touch other elements (especially doesn't move them in memory, like it can 
happen with dynamically sized arrays). I don't see why adding/deleting 
graphical objects should invalidate any gpointers - apart from those which 
pointed to the deleted element(s).

I guess it's meant as a means to keep Pd pointers safe - but what situation 
does it try it prevent?
and why are gpointers also invalidated if you add/delete "normal" text objects 
which are not scalars (and so no gpointer could possibly point to it)?

any pointers (no pun intended) to the reasons behind this desigin decision are 
highly appreciated :-)



> Gesendet: Mittwoch, 28. Februar 2018 um 12:17 Uhr
> Von: Fede 
> An: pd-list@lists.iem.at
> Betreff: [PD] stale pointers after object creation (was Re: pix_data issue)
>
> Ok, so it is a combination of editing the canvas and pointer memory
> 
> i don’t think it has to do with saving.
> also, i don’t think it would relate to the previous pix_data pointer issue
> 
> Here’s a patch
> 
> 
> 
> On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig  wrote:
> 
> > On 02/28/2018 10:53 AM, Fede Camara Halac wrote:
> >> Would saving (cmd+s) make pix_data forget a pointer, as in [text] or 
> >> [array] objects when using pointers?
> > 
> > that sounds very fishy to.
> > do you have a patch that exposes the forget-on-save behaviour of [array]
> > or [text]?
> > 
> > gfmdasr
> > IOhannes
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>

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

Re: [PD] Pd-0.48: native english interface

[IOhannes m zmölnig]

On 02/28/2018 12:10 PM, Thomas Grill wrote:
> Thanks Dan!
> My dumb question has been sufficiently answered for me and the archive.


btw, your question triggered a slight change in the Debian packages:
you can now (un)install the translation files separately (they have
moved into their own "puredata-gui-l10n" package).

gfamds
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd-0.48: native english interface

[Dan Wilcox]

Out of curiosity, which method did you end up using? We could add it to the 
readme or at least make that info a more obvious section.

> On Feb 28, 2018, at 12:10 PM, Thomas Grill  wrote:
> 
> Thanks Dan!
> My dumb question has been sufficiently answered for me and the archive.
> best, Thomas
> 
>> Am 26.02.2018 um 15:31 schrieb Dan Wilcox > >:
>> 
>> A fourth option is to have the GUI simply *not* load locale info. Comment 
>> out "load_locale" in pd-gui.tcl's main proc.
>> 
>>> On Feb 26, 2018, at 3:29 PM, Dan Wilcox >> > wrote:
>>> 
>>> A third option, if you build Pd yourself, is to build without translations 
>>> at all:
>>> 
>>> ./configure --disable-locales
>>> make
>>> 
 On Feb 26, 2018, at 3:20 PM, Dan Wilcox > wrote:
 
 You can set the locale to en.UTF-8 on the commandline as documented in 
 po/README.txt: 
 https://github.com/pure-data/pure-data/blob/master/po/README.txt#L44 
 
 
 Another option is to remove the translated .msg files from your Pd 
 installation.
 
> On Feb 26, 2018, at 12:00 PM, pd-list-requ...@lists.iem.at 
>  wrote:
> 
> Date: Mon, 26 Feb 2018 11:23:16 +0100
> From: Thomas Grill >
> To: Pd-List >
> Subject: [PD] Pd-0.48: native english interface
> Message-ID:  >
> Content-Type: text/plain; charset=us-ascii
> 
> Hey all,
> it's probably a dumb question and has hopefully been answered before, but 
> i can't find the answer:
> How do i get rid of the translated interface (menu items, etc.) in 0.48?
> thanks, Thomas
> 
> --
> Thomas Grill
> http://g.org 
 
 Dan Wilcox
 @danomatika 
 danomatika.com 
 robotcowboy.com 
 
 
 
>>> 
>>> 
>>> Dan Wilcox
>>> @danomatika 
>>> danomatika.com 
>>> robotcowboy.com 
>>> 
>>> 
>>> 
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>> 
>> 
>> 
> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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

[PD] stale pointers after object creation (was Re: pix_data issue)

[Fede]

Ok, so it is a combination of editing the canvas and pointer memory

i don’t think it has to do with saving.
also, i don’t think it would relate to the previous pix_data pointer issue

Here’s a patch




stale-pointer.pd
Description: Binary data

On Feb 28, 2018, at 11:24 AM, IOhannes m zmölnig  wrote:

> On 02/28/2018 10:53 AM, Fede Camara Halac wrote:
>> Would saving (cmd+s) make pix_data forget a pointer, as in [text] or [array] 
>> objects when using pointers?
> 
> that sounds very fishy to.
> do you have a patch that exposes the forget-on-save behaviour of [array]
> or [text]?
> 
> gfmdasr
> IOhannes
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

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

Re: [PD] Pd-0.48: native english interface

[Thomas Grill]

Thanks Dan!
My dumb question has been sufficiently answered for me and the archive.
best, Thomas

> Am 26.02.2018 um 15:31 schrieb Dan Wilcox :
> 
> A fourth option is to have the GUI simply *not* load locale info. Comment out 
> "load_locale" in pd-gui.tcl's main proc.
> 
>> On Feb 26, 2018, at 3:29 PM, Dan Wilcox > > wrote:
>> 
>> A third option, if you build Pd yourself, is to build without translations 
>> at all:
>> 
>> ./configure --disable-locales
>> make
>> 
>>> On Feb 26, 2018, at 3:20 PM, Dan Wilcox >> > wrote:
>>> 
>>> You can set the locale to en.UTF-8 on the commandline as documented in 
>>> po/README.txt: 
>>> https://github.com/pure-data/pure-data/blob/master/po/README.txt#L44 
>>> 
>>> 
>>> Another option is to remove the translated .msg files from your Pd 
>>> installation.
>>> 
 On Feb 26, 2018, at 12:00 PM, pd-list-requ...@lists.iem.at 
  wrote:
 
 Date: Mon, 26 Feb 2018 11:23:16 +0100
 From: Thomas Grill >
 To: Pd-List >
 Subject: [PD] Pd-0.48: native english interface
 Message-ID: >
 Content-Type: text/plain; charset=us-ascii
 
 Hey all,
 it's probably a dumb question and has hopefully been answered before, but 
 i can't find the answer:
 How do i get rid of the translated interface (menu items, etc.) in 0.48?
 thanks, Thomas
 
 --
 Thomas Grill
 http://g.org 
>>> 
>>> Dan Wilcox
>>> @danomatika 
>>> danomatika.com 
>>> robotcowboy.com 
>>> 
>>> 
>>> 
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>> 
>> 
>> 
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] readsf re-blocked up-sampled

[Amur Tet]

Dear list,

I am trying to put a [readsf~] inside a sub re-blocked and up-sampled
following a previous conversation[1], using [block~]. Anyway, I don't get
the correct up-sampling factor. Assuming the patch at sr = 44100 hz, the
same for the audio file, blocksize 64 samples, I tried various
configurations with changing blocksize, overlap and up-sampling factor but
without obtaining the wanted result. Any idea? Osx, Pd vanilla 47.1,
quadriphonic soundfile.

Best,
Marco Matteo Markidis

[1]: soundfiler alternative, https://www.mail-archive.com/
search?l=pd-list@lists.iem.at=subject:%22Re%5C%3A+%5C%
5BPD%5C%5D+soundfiler+alternative%5C%3F%22=newest=1

-- 
Ho cambiato l'indirizzo email in mm.marki...@autistici.org . Se non è un
problema, scrivimi a questo nuovo indirizzo email.

I changed my email address in mm.marki...@autistici.org . If it is ok for
you, please write me to this new email address.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pix_data issue

[IOhannes m zmölnig]

On 02/28/2018 10:53 AM, Fede Camara Halac wrote:
> Would saving (cmd+s) make pix_data forget a pointer, as in [text] or [array] 
> objects when using pointers?

that sounds very fishy to.
do you have a patch that exposes the forget-on-save behaviour of [array]
or [text]?

gfmdasr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pix_data issue

[Fede Camara Halac]

Would saving (cmd+s) make pix_data forget a pointer, as in [text] or [array] 
objects when using pointers? (also, perhaps the [pointer] object itself, but I 
havent tested this)




> On Feb 28, 2018, at 9:54 AM, IOhannes m zmölnig  wrote:
> 
> [pix_data] remembers that pointer

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

Re: [PD] pix_data issue

[IOhannes m zmölnig]

On 02/28/2018 10:45 AM, Jack wrote:
> just a little remark : This is [pix_snap] (and not [pix_snapshot]) to
doh.



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pix_data issue

[Jack]

just a little remark : This is [pix_snap] (and not [pix_snapshot]) to
get back pixels buffer from your gfx card to the RAM of your computer ;)
++

Jack



Le 28/02/2018 à 09:54, IOhannes m zmölnig a écrit :
> On 02/27/2018 11:50 PM, Derek Holzer wrote:
>>
>> I can disconnect the Gemlist from the second inlet, so that it is only
>> getting the metro bangs at the first inlet and the X and Y coordinates
>> to analyze at the third and fourth inlet, and still it gives data output.
>>
>> I know that it is still getting the changing video signal and not just
>> reading the last frame that came in the Gemlist, because I use the
>> analysis data to reconstruct the image with audio signals on an external
>> analog vector monitor, and I see that image changing and moving even if
>> the [pix_data] receives no Gemlist.
> 
> what you are seeing is an artifact of the implementation.
> pixel data is handed between objects by means of a pointer into memory
> (which is one of the things stored in the ominous "GemList")
> 
> [pix_data] remembers that pointer so it can access the data whenever you
> "bang" it.
> if you disconnect the 2nd inlet of a [pix_data] object, it will still
> remember the last image you sent it - and you can still access it.
> 
> now the reason why the data is changing, is because Gem does most of
> it's stuff in-place, that is: it doesn't copy each of your 4k video
> frames for every object it goes through. instead all the objects *share*
> the pixel data (which is the reason why you can see "spill over" of
> pix-fx from one branch of your graph to another).
> in your case this means, that the memory where [pix_data] is reading
> from is the same as the memory where [pix_video] is writing to.
> thus [pix_data] sees updated pixels.
> 
> it is somewhat similar to arrays, where a [tabread] sees updated data
> even if you disconnect the "set" message.
> (but probably much less safe - you *might* trigger memory corruption by
> disconnecting [pix_data] and then somehow invalidating the memory it
> reads from - which could be as simple as changing the reslution of
> [pix_video])
> 
>> Also, no scaling transformations I do to the output of [pix_video] or
>> [pix_film] (for example by texturing it on a rectangle with a [scale]
>> object in front of it) have any effect on what is seen by [pix_data].
> 
> hopefully.
> the pix_* space and the openGL space are two entirely different things.
> pixel data resides in the main memory of your computer. [pix_data] gives
> you access to this main memory. [pix_texture] copies the data to your
> gfx card. [scale] and [rotate] and practically all Gem objects (not
> prefixed with pix_) operate directly on te gfx card. whatever is done to
> the image data on the gfx card, has no effect on the contents in main
> memory.
> 
>> Does [pix_data] read the pixel values from some other place than the
>> Gemlist? A buffer of some kind? How can I apply any transformations to
>> what it "sees"?
> 
> 
> the naive way to do that would be using [pix_snapshot] which is the
> inverse of [pix_texture] (it copies image data from the gfx card to the
> main memory).
> (i call it "naive" as it is an execution path not optimized by modern
> gfx cards, so it might be slower than expected.)
> the non-naive solution would be to not require the a transfer from
> gfx-card to main memory and do everything on the gfx card (see also:
> shaders). depending on the task you want to solve, this might be
> feasible or not (in which case go back to [pix_snapshot])
> 
> 
> gfmdasr
> IOhannes
> 
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 


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

[PD] please don't use the l_ia64 extension (was Re: [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks)

[IOhannes m zmölnig]

On 02/28/2018 01:27 AM, Ed Kelly via Pd-list wrote:
> Hmmm.I'm getting this extension on all the externals I compile on this 
> machine.1) When I compiled ofelia as an addon in the openFrameworks file 
> structure2) When I compile my own externals using a modified version of Hans' 
> Makefile
> I don't know where this is specified, but these are the outputs I get!
well, from a generic build system's point of view, the extension is
non-standard.

so your build-system must set them.
i guess that 1) the ofelia build system set the extension for
Linux/amd64 on purpose and that 2) you yourself modified Hans' Makefile
to use that extension.

at least the standard template Makefile [1] doesn't know anything about
"l_ia64", and since you speak of a "modified version" i can only blame
the modification (it's really hard to tell without seeing).

and of ofelia's build system using "l_ia64", i guess that's just
happened in good faith, since Pd *does* look for "l_ia64" on x86_64.
but imho, this is a bug in Pd, hence my PR which fixes it and once fixed
your external will stop to load (as it exploits buggy behaviour).

(luckily there are only a handful deken packages in the archives that
use this extension; i've assembled a list which you can find at the end
of this mail)


gfsamrd
IOhannes

PS: btw, do you know pd-lib-builder? i think it is much nicer than the
old template Makefile.


[1] https://svn.code.sf.net/p/pure-data/svn/trunk/externals/template


# appendix

the following deken packages found on puredata.info use the "l_ia64"
extension for Linux/x86_64 binaries.
packages that have multiple versions uploaded are only mentioned once.
i have not checked whether there's a newer upload of a package that uses
a better extension ("pd_linux")

uploader: ant1r
  pof

uploader: ossia
  ossia

uploader: cuinjune
  ofelia

uploader: chr15m
  maxlib

uploader: avilleret
  pix_opencv
  Cream



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] ofelia v1.0.4: Pd external library written with openFrameworks

[IOhannes m zmölnig]

On 02/28/2018 06:20 AM, Zack Lee wrote:
> Hi IOhannes,
> 
> Thank you for your suggestion.
> I will recompile the external to use .pd_linux then.

btw, you don't need to recompile. a simple rename (of the binary) would
suffice.


gfmadsr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pix_data issue

[IOhannes m zmölnig]

On 02/27/2018 11:50 PM, Derek Holzer wrote:
> 
> I can disconnect the Gemlist from the second inlet, so that it is only
> getting the metro bangs at the first inlet and the X and Y coordinates
> to analyze at the third and fourth inlet, and still it gives data output.
> 
> I know that it is still getting the changing video signal and not just
> reading the last frame that came in the Gemlist, because I use the
> analysis data to reconstruct the image with audio signals on an external
> analog vector monitor, and I see that image changing and moving even if
> the [pix_data] receives no Gemlist.

what you are seeing is an artifact of the implementation.
pixel data is handed between objects by means of a pointer into memory
(which is one of the things stored in the ominous "GemList")

[pix_data] remembers that pointer so it can access the data whenever you
"bang" it.
if you disconnect the 2nd inlet of a [pix_data] object, it will still
remember the last image you sent it - and you can still access it.

now the reason why the data is changing, is because Gem does most of
it's stuff in-place, that is: it doesn't copy each of your 4k video
frames for every object it goes through. instead all the objects *share*
the pixel data (which is the reason why you can see "spill over" of
pix-fx from one branch of your graph to another).
in your case this means, that the memory where [pix_data] is reading
from is the same as the memory where [pix_video] is writing to.
thus [pix_data] sees updated pixels.

it is somewhat similar to arrays, where a [tabread] sees updated data
even if you disconnect the "set" message.
(but probably much less safe - you *might* trigger memory corruption by
disconnecting [pix_data] and then somehow invalidating the memory it
reads from - which could be as simple as changing the reslution of
[pix_video])

> Also, no scaling transformations I do to the output of [pix_video] or
> [pix_film] (for example by texturing it on a rectangle with a [scale]
> object in front of it) have any effect on what is seen by [pix_data].

hopefully.
the pix_* space and the openGL space are two entirely different things.
pixel data resides in the main memory of your computer. [pix_data] gives
you access to this main memory. [pix_texture] copies the data to your
gfx card. [scale] and [rotate] and practically all Gem objects (not
prefixed with pix_) operate directly on te gfx card. whatever is done to
the image data on the gfx card, has no effect on the contents in main
memory.

> Does [pix_data] read the pixel values from some other place than the
> Gemlist? A buffer of some kind? How can I apply any transformations to
> what it "sees"?


the naive way to do that would be using [pix_snapshot] which is the
inverse of [pix_texture] (it copies image data from the gfx card to the
main memory).
(i call it "naive" as it is an execution path not optimized by modern
gfx cards, so it might be slower than expected.)
the non-naive solution would be to not require the a transfer from
gfx-card to main memory and do everything on the gfx card (see also:
shaders). depending on the task you want to solve, this might be
feasible or not (in which case go back to [pix_snapshot])


gfmdasr
IOhannes





signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list