Re: [PD] For sample players based on [line~], [vline~], or [phasor~], how can we be sure all samples are being played?

[Thomas Grill]

As a followup on that old thread:

- I strongely advice against the use of line~ to drive tabread4~. Under the 
hood, it works with single precision, so that the sample positions are prone to 
round off errors pretty quickly.
Make the test and send the output of [line~] to [print~]. In the simplest case 
of sending a [0, 44100 1000( message to line (and sending a bang to [print~] at 
the same time), the output should show incremented sample positions by exactly 
one. It is easy to see that the numbers are off integers quite quickly.

- vline~ works with double precision and doesn't show the same numeric 
problems, but has a different issue, which i consider a severe bug.
Doing the same as above, the output of [vline~] starts with 1, not with 0 !
This can be circumvented by delaying the output of vline~ by a sample, e.g. by 
sending [0, 44100 1000 0.0226757(, but this is certainly a bad workaround.


The test patch is this:

#N canvas 68 90 450 300 10;
#X obj 26 98 print~;
#X obj 26 16 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1;
#X msg 58 42 0 \, 44100 1000;
#X obj 58 65 line~;
#X text 99 66 or vline~;
#X connect 1 0 2 0;
#X connect 1 0 0 0;
#X connect 2 0 3 0;
#X connect 3 0 0 0;


--
Thomas Grill
http://g.org



> Am 23.03.2015 um 05:50 schrieb Reed Perkins :
> 
> Hi Jonathan. Thank you for the reply. I still have a question about something 
> you wrote, with my original question reproduced below:
> 
> 3. Does the output of [line~] and [vline~] vary due to being asked to 
> generate a ramp faster or slower? If I ask [line~] to go from 0-555987 in 
> 3789 milliseconds, will the actual output be the same or different if I then 
> ask [line~] to go from 0-9876545 in 40 milliseconds
> 
> ​You wrote: "I'm not sure what you're asking.  Are you asking whether the 
> samples output from 0-555987 will be the same in both cases?  If so, the 
> answer is no.  The [line~] object is outputting floating point numbers in the 
> range you specify, over the duration you specify, aligned to block 
> boundaries."
> 
> What I meant to ask is whether or not [phasor~], [line~], and [vline~] behave 
> the same in terms of outputting sequential values regardless of the "speed" 
> they are "driven at".
> 
> From what I understand now, if you "drive" [line~] at the speed of the sample 
> rate, the output should be a steady stream of numbers that increase by 1 from 
> number to number.​ However, if you try to "drive" [line~]​ at a speed that is 
> faster or slower than the sample rate, you'll get dropped samples or 
> duplicated samples, respectively. So in this example:
> 
> [0, 40999 1000( <--jump to 0, then read from 0-40999 in 1000 ms
> |
> [line~]
> |
> [tabread4~ array1] <--where array1 is a size of 41000
> 
>   • If we were to print the output of the first ten ​numbers of [line~]​, 
> it should look like this: 0,​ ​1, 2, 3, 4, 5, 6, 7, 8, 9​.​​
>   • If we change the time in the message box to 2000, does the output of 
> line become 0, 0, 1, 1, 2, 2, 3, 3, 4, because we are now taking twice as 
> long to read through the table?
>   • If we change the time in the message box to 500, does the output of 
> the [line~] become 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, because now [line~] has 
> to skip samples in order to reach the end goal of 40999 in time?
> I did some tests using the patch I outlined above using [print~] and these 
> stipulations seems to hold true. So now I am curious about what [tabread4~]​ 
> does. For the second scenario I outlined (2000ms time), does [tabread4~] 
> change 0, 0, 1, 1, 2, 2, 3, 3, 4, 4... into 0, 0.5, 1, 1.5, 2, 2.5, 3, 3.5, 
> 4, 4.5...? Or in the third scenario (500ms time), does [tabread4~] change, 0, 
> 2, 4, 6, 8, 10... into 0, 1, 2, 3, 4, 5, 6...?
> 
> ​
> On Sun, Mar 22, 2015 at 10:43 AM, Jonathan Wilkes via Pd-list 
>  wrote:
> > On 03/20/2015 12:57 PM, Reed Perkins wrote:
> >
> > Hello all,
> >
> > [line~], [vline~], and [phasor~] are used to generate line ramps in basic
> > sample-playback patches. The output of these objects is usually multiplied
> > by the total number of samples in a sound file (that has already been loaded
> > into an array or table) and fed into the input of something like
> > [tabread4~]. In other words, we use these line-ramp objects to traverse the
> > indices of a table where a sample is loaded at a given speed.
> >
> > My questions are these:
> >
> > 1. Do these line-ramps generate enough numbers such that every sample in a
> > table will be read?
> >
> >
> > No.  (And I assume you are wanting the values of the table to be output one
> > after the other, in sequence, when you output them as a signal.)
> >
> > The determining factors for how table values are output: a) ramp duration
> > (in time units), b) ramp height (end value - start value), c) the sample
> > rate, and d) whether the object doing the reading is interpolating the index
> > values.
> >
> > The sample rate in Pd is fixed, so you are only guaranteed to read every
> 

Re: [PD] Obfuscate patch?

[Christof Ressi]

:-D

> Gesendet: Donnerstag, 12. Mai 2016 um 23:43 Uhr
> Von: "IOhannes m zmölnig" 
> An: pd-list@lists.iem.at
> Betreff: Re: [PD] Obfuscate patch?
>
> On 05/12/2016 08:52 PM, Jeff Sandys wrote:
> >> Or use Braille font in a live performance.
> 
> who would do such a thing?
> 
> gmadsr
> 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] Can you close source of Pd patches (for commercial development)?

[Jonathan Wilkes via Pd-list]

Don't ship the entire patch.
For example, suppose I'm selling a patch where the user can input single word 
"easing" styles like "ease-in-out", "rubber-band", "drunken-walk", etc., and 
it outputs lists of numbers that can be input into [vline~].  I'd do it this 
way:
[style-name(|[my-abstraction]|[ (|[vline~]
Which I can ship as
[style-name(|[netsend]
[netreceive]|[ (|[vline~]

I'm ignoring the interface for netsend/netreceive for the moment, but you 
get the idea.  The "business" logic stays on your machine, and remains a 
black box to your agent until you trust him/her.
 
-Jonathan


On Thursday, May 12, 2016 6:28 AM, Lorenzo Sutton 
 wrote:
 

 On 07/05/2016 18:14, Matti Viljamaa wrote:
> Wonder e.g. why the Max platform is more popular, even if its
> commercial. Commerciality isn’t stopping people from using it.

What kind of (scientific) research have you conducted to conclude that 
"Max platform is more popular"?

What is your definition and criteria for "popularity"?
What is your sample group(s)?
What data have you collected and taken into account to support your 
statement?

Thanks.

___
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] Obfuscate patch?

[IOhannes m zmölnig]

On 05/12/2016 08:52 PM, Jeff Sandys wrote:
>> Or use Braille font in a live performance.

who would do such a thing?

gmadsr
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] Obfuscate patch?

[Dan Wilcox]

You could go the computer game approach and use a custom binary packing 
algorithm where you compress all of that data into a single file which your 
program then unpacks when it runs everything. That is assuming that you have a 
sort of main program that runs the system. People *might* reverse-engineer your 
format (ie. the DOOM WAD file), but probably the number of people interested in 
doing so will be small.

Since pd patches are just text files, you could use any text to binary encoding 
format etc. This of course starts heading into encryption territory, but that’s 
a whole other thing there...


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On May 12, 2016, at 1:47 PM, pd-list-requ...@lists.iem.at wrote:
> 
> So, the only thing I can do... is to obfuscate as much I can.
> 
> Python: strings, keys, values, functions, classes, etc
> Blender: objects, bones, scenes, materials and textures names, inserting 
> extra scenes, textures, etc
> JSON: everything.
> PureData: send/receive names, messages from/to Blender, moving boxes, adding 
> extra objects, etc.
> 
> And, of course, all that obfuscated names have to be the same between the 
> files.

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

Re: [PD] error installing Pd 0.47 OSX

[Dan Wilcox]

I can confirm the latest commit bindings are working fine for me. It’s 
definitely a “go figure” thing, but if binding to both works for Safari, 
Chrome. etc then it’s good enough for Pd. :)

(At least it’s easier than doing some sort of locale based checking…)


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On May 11, 2016, at 10:52 PM, Dan Wilcox  wrote:
> 
> I think it means, as per IOhannes’ mail, that we should bind to both + and =. 
> That’s what the web browsers do to get around this problem. Sorry it didn’t 
> occur to me with my US-centric keyboard mentality ;P
> 
> I will, however, reiterate that Shift and + is awkward and unneeded on the US 
> keyboard.
> 
> 
> Dan Wilcox
> EDP Visiting Teaching Assistant Professor
> Shwayder 215
> @danomatika 
> danomatika.com 
> robotcowboy.com 
>> On May 11, 2016, at 1:42 PM, Miller Puckette > > wrote:
>> 
>> That was in response to the opposite feedback I was getting, for instance
>> here:
>> 
>> https://lists.puredata.info/pipermail/pd-list/2016-05/114538.html 
>> 
>> 
>> ... so does this mean Pd should zoom in for either cmd-= OR cmd-+?
>> 
>> cheers
>> Miller
>> On Wed, May 11, 2016 at 09:17:45PM +0200, IOhannes m zmölnig wrote:
>>> On 05/11/2016 07:47 PM, Marco Matteo Markidis wrote:
 Moreover, zoom in function works with cmd+= (not with cmd++).
>>> 
>>> i can confirm this on linux.
>>> on a german keyboard layout, one of the test-releases did zoom with
>>> Ctrl-+, but in the final release it has become
>>> Ctrl-= :-(
>>> 
>>> gmrds
>>> IOhannes
>>> 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Obfuscate patch?

[Jeff Sandys]

Message: 5
> On Thu, 12 May 2016 13:46:55 +0200, IOhannes m zmoelnig wrote:
> On 2016-05-12 12:09, Lorenzo Sutton wrote:
> > On 12/05/2016 05:57, Mario Mey wrote:
> >> Is already done any external/abstract/external-program that obfuscate a
> >> Pd patch? ...
> >> to make very hard to understand, etc...?
>
> yes, iirc multiple times.
> - [parazit] (used to be shipped with Pd-extended)
> - i remember a few patches from the local pd~graz gang around 2004 that
> would go into that direction (including self-destruction)
> - personally i have used self-replicating, self-renaming and moving
> objects in a number of performances [sinusoiddreams]
> (much of the iemguts development was driven to implement those systems).
>
> Or use Braille font in a live performance.

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

Re: [PD] Obfuscate patch?

[Mario Mey]

Thanks everybody.

Why would you want to do something like that?


I live in Argentina and I'm going to work with an agent in Spain. I 
developed and I offer the service of "Digital Puppeteers". So, this 
agent will offer the same service and he will contact me when he find a 
client. So, I prepare "the files" and I send him... and he pay to me.


Now, "the files" are the important thing here. They are Blender, Python, 
JSON and PureData files. Somehow, no-one of that formats can be compiled 
to send him the binary. Also, I can't afford contracting a hardware key 
system... or pay a programmer to make some online validation code.


If I send the files as they are in my computer (clean code, 
documentation, etc), in the worst case, he could never call me back... 
and start using the files for him, changing a few graphic files, audio 
files, code lines, patches, etc.


So, the only thing I can do... is to obfuscate as much I can.

Python: strings, keys, values, functions, classes, etc
Blender: objects, bones, scenes, materials and textures names, inserting 
extra scenes, textures, etc

JSON: everything.
PureData: send/receive names, messages from/to Blender, moving boxes, 
adding extra objects, etc.


And, of course, all that obfuscated names have to be the same between 
the files.



What about simply changing all object coords other than inlet/outlet to (0, 0)?

Good one.

yes, iirc multiple times.
- [parazit] (used to be shipped with Pd-extended)
- i remember a few patches from the local pd~graz gang around 2004 that
would go into that direction (including self-destruction)
- personally i have used self-replicating, self-renaming and moving
objects in a number of performances [sinusoiddreams]
(much of the iemguts development was driven to implement those systems).

I'll look at them!

kinda antithetical to the ethos of Pure Data
I posted my biggest PureData project in PatchStorage (and the old one, 
too). This patch is very specific.

among other reasons, http://www.ioccc.org/
When I saw inside the code files... it made sense to me. They made me 
laught.

I am an external patch obfuscator; nobody can understand the things that I 
write in PD.

I will hire you! :D

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

Re: [PD] Obfuscate patch?

[Liam Goodacre]

I am an external patch obfuscator; nobody can understand the things that I 
write in PD.

> To: pd-list@lists.iem.at
> From: mario...@gmail.com
> Date: Thu, 12 May 2016 00:57:10 -0300
> Subject: [PD] Obfuscate patch?
> 
> Is already done any external/abstract/external-program that obfuscate a 
> Pd patch? I mean, by changing the place of every object, changing names 
> of send/receive objects to random generated names, adding more objects 
> to make very hard to understand, etc...?
> 
> ___
> 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] error installing Pd 0.47 OSX

[Dan Wilcox]

The script is not there yet as I’m working on it in another branch. Still needs 
some testing.

As it is now, using the current Tk 8.5 with OSX is a *bad* idea as it has all 
sorts of problems. Using a newer TK that is downloaded and built fixes all of 
that and the retina font rendering looks awesome.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On May 12, 2016, at 10:21 AM, me.grimm  wrote:
> 
> This is part of autotools now?
> 
> I am assuming you are not done but will soon let us know to test :)

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

Re: [PD] error installing Pd 0.47 OSX

[me.grimm]

Hey Dan,

This is pretty awesome work. Thanks for putting all the time, frustration
and energy into a solid OSX building strategy.  I feel like mac OS has been
slightly neglected since Hans departure. So speaking from as a mac user,
thank you!

>>>Thanks. I have a script now which will download and build Tk for you.

This is part of autotools now?

I am assuming you are not done but will soon let us know to test :)

BTW can I pitch you some bitcoin tip (it won't be much but its something)?
I hear BTC will double in next couple months due to reward halving so you
can pretend the tip is x2...

m

On Thu, May 12, 2016 at 11:49 AM, Dan Wilcox  wrote:

>
> Dan your autotools update is great. I installed all with no problem.
> Moreover I done make app; great news!
>
> Some general observation on OS X compilation: I get several warnings,
> like:
> a) libtool: warning: libobj name 'pd~.lo' may not contain shell special
> characters.
>
>
> That’s not a problem, just libtool not liking the tilde in the file name.
>
> The rest are just a few warnings in PoartAudio, also not major problems.
> The real issue with PA is that it still relies
> on the deprecated Carbon framework and we ignore those warnings for now.
>
> So, great work!
>
>
> Thanks. I have a script now which will download and build Tk for you. For
> some reason, one combination of Tk + Pd (universal maybe) I tried, suddenly
> made Gem work again. I’ll see if I can find that combo again…
>
> 
> 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
>
>


-- 

m.e.grimm, m.f.a, ed.m.
syracuse u., tc3
megrimm.net

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

Re: [PD] error installing Pd 0.47 OSX

[Dan Wilcox]

> Dan your autotools update is great. I installed all with no problem. Moreover 
> I done make app; great news!
> 
> Some general observation on OS X compilation: I get several warnings, like: 
> a) libtool: warning: libobj name 'pd~.lo' may not contain shell special 
> characters.

That’s not a problem, just libtool not liking the tilde in the file name.

The rest are just a few warnings in PoartAudio, also not major problems. The 
real issue with PA is that it still relies
on the deprecated Carbon framework and we ignore those warnings for now.

> So, great work!

Thanks. I have a script now which will download and build Tk for you. For some 
reason, one combination of Tk + Pd (universal maybe) I tried, suddenly made Gem 
work again. I’ll see if I can find that combo again…


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] ICLI 2016 - Registration open

[thor]

3rd International Conference on Live Interfaces
School of Media, Film and Music - University of Sussex, Brighton.

Dates: June 28th - July 2nd, 2016.
Website: www.liveinterfaces.org

Registration is now open for the International Conference on Live Interfaces in 
Brighton this summer. This biennial conference brings together people working 
with live interfaces in the performing arts, including music, the visual arts, 
dance, puppetry, robotics or games. The conference scope is highly 
interdisciplinary but with a focus on interface technologies of expression in 
the area of performance. Topics of liveness, immediacy, presence (and 
tele-presence), mediation, collaboration and timing or flow are engaged with 
and questioned in order to gain a deeper understanding of the role contemporary 
media technologies play in human expression.

The conference consists of paper presentations, performances, interactive 
installations, poster demonstrations, a doctoral colloquium and workshops. 
Works engaging with the principles and assumptions governing interaction 
design, including perspectives from art, philosophy, product design and 
engineering are specially invited.

Keynotes:
- Stuart Nolan (magician)
- Kristina Andersen (instrument maker)
- Roman Paska (puppeteer)

Workshops:
- Magnetic Resonator Piano (Andrew McPherson)
- The halldorophone (Halldor Ulfarsson)
- Sound and Space: Performing Music for Organ and Electronics (Lauren Redhead 
and Alistair Zaldua)
- A Practical and Theoretical Introduction to Chaotic Musical Systems (Tristan 
Clutterbuck, Tom Mudd and Dario Sanfilippo)
- Making High-Performance Embedded Instruments with Bela and Pure Data (Giulio 
Moro, Astrid Bin, Robert Jack, Christian Heinrichs and Andrew McPherson)
- Distributed Agency in Performance (Paul Stapleton, Simon Waters, Owen Green 
and Nicholas Ward)
- Interfacing the Txalaparta Workshop (Enrike Hurtado)

The conference, including performances and installations, will take place at 
the newly renovated Attenborough Centre for the Creative Arts. We will publish 
final performance, installations and paper programme when closer in time.

There is a doctoral colloquium on Wednesday 29th of June and a Brighton Modular 
Meet on Sunday, 3rd of July.

We look forward to welcome you to the University of Sussex for the ICLI 
conference this summer.

Best,
Thor

---
Thor Magnusson
Department of Music
School of Media, Film and Music
University of Sussex
http://www.sussex.ac.uk/profiles/164902
http://www.ixi-audio.net
https://twitter.com/thormagnusson
---___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Obfuscate patch?

[Lorenzo Sutton]

On 12/05/2016 13:46, IOhannes m zmoelnig wrote:

On 2016-05-12 12:09, Lorenzo Sutton wrote:

On 12/05/2016 05:57, Mario Mey wrote:

Is already done any external/abstract/external-program that obfuscate a
Pd patch? I mean, by changing the place of every object, changing names
of send/receive objects to random generated names, adding more objects
to make very hard to understand, etc...?


[...]




Why would you want to do something like that?



among other reasons, http://www.ioccc.org/


Ok in that sense, sure... Maybe I was biased by the other thread about 
"commercial" Pd projects...


Still the OP hasn't revealed their real intentions, maybe in an attempt 
to obfuscate them :)


Lorenzo.

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

Re: [PD] Obfuscate patch?

[IOhannes m zmoelnig]

On 2016-05-12 12:09, Lorenzo Sutton wrote:
> On 12/05/2016 05:57, Mario Mey wrote:
>> Is already done any external/abstract/external-program that obfuscate a
>> Pd patch? I mean, by changing the place of every object, changing names
>> of send/receive objects to random generated names, adding more objects
>> to make very hard to understand, etc...?

yes, iirc multiple times.
- [parazit] (used to be shipped with Pd-extended)
- i remember a few patches from the local pd~graz gang around 2004 that
would go into that direction (including self-destruction)
- personally i have used self-replicating, self-renaming and moving
objects in a number of performances [sinusoiddreams]
(much of the iemguts development was driven to implement those systems).


> 
> Why would you want to do something like that?
> 

among other reasons, http://www.ioccc.org/

and why would anybody want to use a ring modulator, a 6/8 metrum or Pd?


fgmsdr
IOhannes


[parazit] https://lists.puredata.info/pipermail/pd-list/2005-05/028458.html
[sinusoiddreams] e.g. https://vimeo.com/56004131



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] Preferred/best practice for loading external objects

[Jack]

Hello,

Just a suggestion : it is a good thing to move all externals in
~/.local/lib/pd/extra/ but it would be a good point if it is possible to
remove them using deken (and maybe remove path ?).
I don't know if it is easily doable/possible/advisable.
++

Jack



Le 10/05/2016 13:41, Chris McCormick a écrit :
> On 09/05/16 16:27, IOhannes m zmoelnig wrote:
>> so i'm all for moving to ~/.local/lib/pd/extra/
>> (and/or ~/.local/lib/pd/0.47-3/extra/ if somebody thinks this is useful)
>> PS: i don't think that ~/.config/ is the right place to put externals
>> https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>
> 
> Agree, sounds good!
> 
> Cheers,
> 
> Chris.
> 


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

Re: [PD] error installing Pd 0.47 OSX

[Marco Matteo Markidis]

Dear all,

Dan your autotools update is great. I installed all with no problem.
Moreover I done make app; great news!

Some general observation on OS X compilation: I get several warnings, like:
a) libtool: warning: libobj name 'pd~.lo' may not contain shell special
characters. b) pm_mac/readbinaryplist.c:87:9: warning: 'MAXPATHLEN' macro
redefined [-Wmacro-redefined]

#define MAXPATHLEN 256

   ^

/usr/include/sys/param.h:196:9: note: previous definition is here

#define MAXPATHLEN  PATH_MAX

^

pm_mac/readbinaryplist.c:386:17: warning: 'FSFindFolder' is deprecated:
first deprecated in OS X 10.8

  [-Wdeprecated-declarations]

OSErr err = FSFindFolder(kOnAppropriateDisk, folder_type,

^

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Folders.h:286:1:
note:

  'FSFindFolder' has been explicitly marked deprecated here

FSFindFolder(

^

pm_mac/readbinaryplist.c:392:11: warning: 'FSRefMakePath' is deprecated:
first deprecated in OS X 10.8

  [-Wdeprecated-declarations]

err = FSRefMakePath(&prefdir, (UInt8 *) cstr, (UInt32) (MAXPATHLEN -
1));

  ^

/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:4086:18:
note:

  'FSRefMakePath' has been explicitly marked deprecated here

extern OSStatus  FSRefMakePath(const FSRef *ref, UInt8 *path, UInt32
pathBufferSize) __OSX_...

 ^

3 warnings generated.

This is my configuration:
configure:


pd 0.47.0 is now configured


Platform: Mac OSX

Debug build:  yes

Universal build:  no

Localizations:no

Source directory: .

Installation prefix:  /usr/local
Compiler: gcc

CFLAGS:   -g -O0 -g -O2

LDFLAGS:   -L/usr/local/lib -L/opt/local/lib

INCLUDES:  -I/opt/local/include


External extension:   pd_darwin

External CFLAGS:  -fPIC

External LDFLAGS: -bundle -undefined dynamic_lookup


fftw: yes


audio APIs:   PortAudio JACK

midi APIs:PortMidi

So, great work!

Thank you.

Marco

2016-05-12 6:56 GMT+02:00 Dan Wilcox :

> I think it means, as per IOhannes’ mail, that we should bind to both + and
> =. That’s what the web browsers do to get around this problem. Sorry it
> didn’t occur to me with my US-centric keyboard mentality ;P
>
> I will, however, reiterate that Shift and + is awkward and unneeded on the
> US keyboard. :)
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
> On May 11, 2016, at 1:42 PM, Miller Puckette  wrote:
>
> That was in response to the opposite feedback I was getting, for instance
> here:
>
> https://lists.puredata.info/pipermail/pd-list/2016-05/114538.html
>
> ... so does this mean Pd should zoom in for either cmd-= OR cmd-+?
>
> cheers
> Miller
> On Wed, May 11, 2016 at 09:17:45PM +0200, IOhannes m zmölnig wrote:
>
> On 05/11/2016 07:47 PM, Marco Matteo Markidis wrote:
>
> Moreover, zoom in function works with cmd+= (not with cmd++).
>
>
> i can confirm this on linux.
> on a german keyboard layout, one of the test-releases did zoom with
> Ctrl-+, but in the final release it has become
> Ctrl-= :-(
>
> gmrds
> 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] Can you close source of Pd patches (for commercial development)?

[Lorenzo Sutton]

On 07/05/2016 18:14, Matti Viljamaa wrote:

Wonder e.g. why the Max platform is more popular, even if its
commercial. Commerciality isn’t stopping people from using it.


What kind of (scientific) research have you conducted to conclude that 
"Max platform is more popular"?


What is your definition and criteria for "popularity"?
What is your sample group(s)?
What data have you collected and taken into account to support your 
statement?


Thanks.

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

Re: [PD] Obfuscate patch?

[Lorenzo Sutton]

On 12/05/2016 05:57, Mario Mey wrote:

Is already done any external/abstract/external-program that obfuscate a
Pd patch? I mean, by changing the place of every object, changing names
of send/receive objects to random generated names, adding more objects
to make very hard to understand, etc...?



Why would you want to do something like that?

Lorenzo.

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

Re: [PD] Obfuscate patch?

[Max]

On 2016년 05월 12일 16:08, Scott R. Looney wrote:
though i believe
> that could affect signal flow and execution order, wouldn't it?

that's a Max problem, fixed in Pd, the only thing is that you should be
careful with the outlet positions of abstractions. The order could change.
m.

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

Re: [PD] Obfuscate patch?

[Scott R. Looney]

i agree - kinda antithetical to the ethos of Pure Data, really. i think you
could use Heavy to turn a patch into rather voluminous C++ code. i remember
from the devs that they said the code output wasn't supposed to be edited
or analyzed by humans, but rather existed to be wrapped to work in a number
of environments as sort of a black box or code blob. but obfuscating a PD
patch itself seems stupid. i'm sure you could name subpatches and
abstractions randomly and maybe even rearrange the physical placement using
the method Jonathan refers to, though i believe that could affect signal
flow and execution order, wouldn't it?

best,
scott



On Wed, May 11, 2016 at 11:54 PM, Alexandre Torres Porres 
wrote:

> but why?
>
> 2016-05-12 3:03 GMT-03:00 Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at>:
>
>> What about simply changing all object coords other than inlet/outlet to
>> (0, 0)?
>>
>> -Jonathan
>>
>>
>> On Thursday, May 12, 2016 12:00 AM, Mario Mey  wrote:
>>
>>
>> Is already done any external/abstract/external-program that obfuscate a
>> Pd patch? I mean, by changing the place of every object, changing names
>> of send/receive objects to random generated names, adding more objects
>> to make very hard to understand, etc...?
>>
>> ___
>> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list