Re: [PD] 0.47.1 tcl issue

[Miller Puckette]

Yes... 0.47 simply doesn't work on Macs that don't have tcl8.4 installed.
There's no choice but to go to 0.48.

I'm just about to release 0.48-1 test 1 - I hope that helps with the font size
problems.

cheers
Miller

On Mon, Dec 04, 2017 at 12:30:33PM +0900, Matt Davey wrote:
> hi, just tried installing both the 32 and 64 bit vanilla builds on newly
> updated macbook with OSX 10.13.1, and get error pasted below.
> 
> so, i checked, and it seems this version of OSX only comes with tcl 8.5,
> not 8.4.
> 
> is there a simple way to get this working here?
> 
> For the record, the newest version of pd, 0.48-0 seems to work
> fine...except for that annoying font size issue, which currently renders it
> unusable for me.
> 
> 
> 
> 
> *Crashed Thread:0*
> 
> 
> *Exception Type:EXC_CRASH (SIGABRT)*
> 
> *Exception Codes:   0x, 0x*
> 
> *Exception Note:EXC_CORPSE_NOTIFY*
> 
> 
> *Termination Reason:DYLD, [0x1] Library missing*
> 
> 
> *Application Specific Information:*
> 
> *dyld: launch, loading dependent libraries*
> 
> 
> *Dyld Error Message:*
> 
> *  Library not loaded:
> /System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl*
> 
> *  Referenced from: /Applications/Pd-0.47-1-64bit.app/Contents/MacOS/Pd*
> 
> *  Reason: image not found*

> ___
> 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] 0.47.1 tcl issue

[Matt Davey]

hi, just tried installing both the 32 and 64 bit vanilla builds on newly
updated macbook with OSX 10.13.1, and get error pasted below.

so, i checked, and it seems this version of OSX only comes with tcl 8.5,
not 8.4.

is there a simple way to get this working here?

For the record, the newest version of pd, 0.48-0 seems to work
fine...except for that annoying font size issue, which currently renders it
unusable for me.




*Crashed Thread:0*


*Exception Type:EXC_CRASH (SIGABRT)*

*Exception Codes:   0x, 0x*

*Exception Note:EXC_CORPSE_NOTIFY*


*Termination Reason:DYLD, [0x1] Library missing*


*Application Specific Information:*

*dyld: launch, loading dependent libraries*


*Dyld Error Message:*

*  Library not loaded:
/System/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl*

*  Referenced from: /Applications/Pd-0.47-1-64bit.app/Contents/MacOS/Pd*

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

Re: [PD] Camomile v0.1.0 - pre-release

[Lucas Cordiviola]

Hi Pierre,

I'm testing on windows and my host doesn't load Camomile:

Analysis with http://www.dependencywalker.com/ shows that "Camomile.dll" 
is calling "libpd.dll" which is not present anywhere on 
"CamomileWindows.zip".

Apart from that it seems "Camomile.dll" is compiled for 64bit. My host 
(ableton live 7) does not load 64bit VSTs.

Do I open an issue @ the git?



Mensaje telepatico asistido por maquinas.

On 12/3/2017 10:38 AM, Pierre Guillot wrote:
> it would be great if some of you could give me feedback on Linux and 
> Window (on MacOS also). At least to know if it works. 

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

Re: [PD] Force cyclone/gate instead of iemlib1/gate

[Alexandre Torres Porres]

Sorry, I don't think I understand the issue, or what you mean or ask. But
let me join in anyway.

2017-12-03 15:49 GMT-02:00 Lucas Cordiviola :

> IMO [cyclone/gate] is the "correct" way.
>

There are several externals that have the same name, and there are ways to
control this and call the one you want. The one that is more reliable (or
"correct") to me is libname/objectname, indeed.

In the old days of Pd-Extended, libraries would already be loaded by
default, and cyclone would come first. That means [gate]instantiates
cyclone's instead of iemlib's

Now, with Pd Vanilla, you can set the order your own, or use [declare],
but, again, I just think libname/objectname is easier and more explicit

hope I helped

cheers



>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
> On 12/3/2017 2:18 PM, Jérôme Abel wrote:
> > Hi list,
> >
> > We noticed in the Malinette
> > (https://framagit.org/malinette/malinette-soft) that the [gate]
> > external from iemlib1 replace the cyclone one (the old version, not
> > the beta).
> >
> > In Linux, I don't need to add "-lib iemlib1" to get [para_bp~]
> > external (filter object). But on Windows, I need to add this option
> > and iemlib1 seems stronger (order does not affect this) than cyclone
> > import.
> >
> > The "bad" way woud be to write all objects with [cyclone/gate] but if
> > someone has a better way...
> >
> > 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] Force cyclone/gate instead of iemlib1/gate

[Lucas Cordiviola]

IMO [cyclone/gate] is the "correct" way.


--

Mensaje telepatico asistido por maquinas.

On 12/3/2017 2:18 PM, Jérôme Abel wrote:
> Hi list,
>
> We noticed in the Malinette 
> (https://framagit.org/malinette/malinette-soft) that the [gate] 
> external from iemlib1 replace the cyclone one (the old version, not 
> the beta).
>
> In Linux, I don't need to add "-lib iemlib1" to get [para_bp~] 
> external (filter object). But on Windows, I need to add this option 
> and iemlib1 seems stronger (order does not affect this) than cyclone 
> import.
>
> The "bad" way woud be to write all objects with [cyclone/gate] but if 
> someone has a better way...
>
> Thanks
>

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

[PD] Force cyclone/gate instead of iemlib1/gate

[Jérôme Abel]

Hi list,

We noticed in the Malinette 
(https://framagit.org/malinette/malinette-soft) that the [gate] external 
from iemlib1 replace the cyclone one (the old version, not the beta).


In Linux, I don't need to add "-lib iemlib1" to get [para_bp~] external 
(filter object). But on Windows, I need to add this option and iemlib1 
seems stronger (order does not affect this) than cyclone import.


The "bad" way woud be to write all objects with [cyclone/gate] but if 
someone has a better way...


Thanks

--
Jérôme Abel
http://jeromeabel.net
http://reso-nance.org


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

[PD] Camomile v0.1.0 - pre-release

[Pierre Guillot]

Hi,

I've been working on the new (major) version of the plugin Camomile, a
plugin (VST/VST3/AU) that loads Pure Data patches. It's not ready yet but
pre-releases (v0.1.0-beta5) are available for MacOS, Linux and Windows. I
compiled online because I have neither a Linux nor a Windows machine. I
test everything on MacOS, it would be great if some of you could give me
feedback on Linux and Window (on MacOS also). At least to know if it works.

https://github.com/pierreguillot/Camomile/releases

For the moment, the documentation only explains how to use the plugins not
how to create new ones. I will update and complete the documentation in the
next weeks and feel free to ask me in the meantime.
Cheers,

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

Re: [PD] autotools

[Christof Ressi]

maybe for MinGW, automake could just pass the right variables to 
makefile.mingw? I could also rework the MinGW makefiles for the externals so 
that they don't depend on pd-lib-builder.


Gesendet: Sonntag, 03. Dezember 2017 um 13:42 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list 
Betreff: Re: [PD] autotools

Yeah, I'm looking into not using libtool actually, partially for this reason. 
We are using it with port audio and port midi, but it's not really required for 
things which are only statically linked in the project. The dll we could leave 
as something we do more by hand as we (you!) have worked out the set of steps 
needed.
 
it's recommended to only use libtool for when it's actually necessary and this 
is really for building cross-platform shared libraries. It will be great for 
libpd, for instance, but I'm thinking now we don't really need it for desktop 
Pd.

 

On Dec 3, 2017, at 1:39 PM, Christof Ressi 
 wrote: 

Yeah and that's largely due to the current layout being recursive,
hmmm.. I don't think that's the reason. currently, there aren't that many 
Makefiles: /src, /portaudio, /portmidi, /asio, /extra and for each external. 
aside from that, my build system is also recursive (calling make on 
pd-lib-builder makefiles for the externals). 
what's really slow is compiling the individual source files. while a typical .c 
file in /src takes ~1 second on my build system, it takes significantly longer 
with libtool. this is easily noticeable when watching the console output. I 
think it's rather an overhead introduced by libtool but I might be wrong. did 
you notice that on other platforms?  


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 

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

Re: [PD] autotools

[Dan Wilcox]

Yeah, I'm looking into not using libtool actually, partially for this reason. 
We are using it with port audio and port midi, but it's not really required for 
things which are only statically linked in the project. The dll we could leave 
as something we do more by hand as we (you!) have worked out the set of steps 
needed.

it's recommended to only use libtool for when it's actually necessary and this 
is really for building cross-platform shared libraries. It will be great for 
libpd, for instance, but I'm thinking now we don't really need it for desktop 
Pd.

> On Dec 3, 2017, at 1:39 PM, Christof Ressi  wrote:
> 
>> Yeah and that's largely due to the current layout being recursive,
> 
> hmmm.. I don't think that's the reason. currently, there aren't that many 
> Makefiles: /src, /portaudio, /portmidi, /asio, /extra and for each external. 
> aside from that, my build system is also recursive (calling make on 
> pd-lib-builder makefiles for the externals). 
> what's really slow is compiling the individual source files. while a typical 
> .c file in /src takes ~1 second on my build system, it takes significantly 
> longer with libtool. this is easily noticeable when watching the console 
> output. I think it's rather an overhead introduced by libtool but I might be 
> wrong. did you notice that on other platforms? 


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] autotools

[Christof Ressi]

> Yeah and that's largely due to the current layout being recursive,

hmmm.. I don't think that's the reason. currently, there aren't that many 
Makefiles: /src, /portaudio, /portmidi, /asio, /extra and for each external. 
aside from that, my build system is also recursive (calling make on 
pd-lib-builder makefiles for the externals). 
what's really slow is compiling the individual source files. while a typical .c 
file in /src takes ~1 second on my build system, it takes significantly longer 
with libtool. this is easily noticeable when watching the console output. I 
think it's rather an overhead introduced by libtool but I might be wrong. did 
you notice that on other platforms? 


Gesendet: Sonntag, 03. Dezember 2017 um 12:55 Uhr
Von: "Dan Wilcox" 
An: "Christof Ressi" 
Cc: pd-list , "Miller Puckette" 
Betreff: Re: [PD] autotools

 

On Dec 3, 2017, at 11:39 AM, Christof Ressi 
 wrote: 
but most other platform specific knowledge will be the same for any build 
system I guess. after all, Pd changes in a slow and healthy pace, so there 
aren't many modifications to be done to the build system once it is set up.
 
That is definitely true. Automake puts together the makefile rules for you but 
of course it still works in the same way in the end.
 
I've also found this guide to be pretty helpful in the getting into the basics: 
https://autotools.io/index.html[https://autotools.io/index.html]
 
the one thing I noticed is build speed: a complete rebuild (including 
externals) on my personal MinGW build system takes ~40 seconds but with 
autotools it takes a whopping 4 minutes and 30 seconds!
 
Yeah and that's largely due to the current layout being recursive, ie. multiple 
makefiles in multiple directories. This is one of the reasons there have been 
some projects that rework things into a single main makefile as it lowers the 
amount of directory walking and intermediate steps ie. non-recursive make: 
https://autotools.io/automake/nonrecursive.html[https://autotools.io/automake/nonrecursive.html]
 
To some degree, configure will always be slow for all sorts of reasons, but 
there are definitely techniques to slow down the make process. Another 
advantage to non-recursive make is that doing a parallel build would work 
without timing uncertainties between different makefiles. 


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 

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

Re: [PD] autotools

[Dan Wilcox]

> On Dec 3, 2017, at 11:39 AM, Christof Ressi  wrote:
> 
> but most other platform specific knowledge will be the same for any build 
> system I guess. after all, Pd changes in a slow and healthy pace, so there 
> aren't many modifications to be done to the build system once it is set up.

That is definitely true. Automake puts together the makefile rules for you but 
of course it still works in the same way in the end.

I've also found this guide to be pretty helpful in the getting into the basics: 
https://autotools.io/index.html 

> the one thing I noticed is build speed: a complete rebuild (including 
> externals) on my personal MinGW build system takes ~40 seconds but with 
> autotools it takes a whopping 4 minutes and 30 seconds!

Yeah and that's largely due to the current layout being recursive, ie. multiple 
makefiles in multiple directories. This is one of the reasons there have been 
some projects that rework things into a single main makefile as it lowers the 
amount of directory walking and intermediate steps ie. non-recursive make: 
https://autotools.io/automake/nonrecursive.html 


To some degree, configure will always be slow for all sorts of reasons, but 
there are definitely techniques to slow down the make process. Another 
advantage to non-recursive make is that doing a parallel build would work 
without timing uncertainties between different makefiles.


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] autotools

[Christof Ressi]

some comments from someone who very recently got into autotools. my personal 
problem was that I thought just because automake generates makefiles, it would 
be similar to make syntax. after I understood it's a totally different system 
and followed some tutorials, I think it's not so hard. there are some quirks 
like getting the right flags for libtool to produce proper Windows DLLs, 
tricking libtool to link with g++ for ASIO etc. but most other platform 
specific knowledge will be the same for any build system I guess. after all, Pd 
changes in a slow and healthy pace, so there aren't many modifications to be 
done to the build system once it is set up.

the one thing I noticed is build speed: a complete rebuild (including 
externals) on my personal MinGW build system takes ~40 seconds but with 
autotools it takes a whopping 4 minutes and 30 seconds!

> 2. hybrid autoconf/makefile: If we want, we can use regular makefile rules in 
> automake files or our own makefiles instead of automake 
> and simply use the configuration variables for autoconf. 

that could also be a good solution. ./configure is definitly great to have!

anyway, just some thoughts, I don't have any real opinion. I'm willing to work 
on whatever build system we finally get.

Gesendet: Sonntag, 03. Dezember 2017 um 03:58 Uhr
Von: "Dan Wilcox" 
An: pd-list 
Cc: "Miller Puckette" 
Betreff: [PD] autotools

I started working on the pd autotools build mainly because I had already used 
autotools before and it seemed like the easiest way to get Pd to build on macOS 
again. So far, we've moved forward with it in general, but at this point I 
wonder if a re-examination makes sense.
 
Some points:
 
1. ./configure && make are great for users -> The more people who can easily 
build Pd, the more help we can get for all sorts of things. I think we've been 
seeing that the last 6 months or so.
 
2. Built-in support for gettext processing, standard install targets, etc allow 
for translations and package management (Debian)
 
3. *Maintaining* the configure.ac & Makefile.am files makes maintaining the 
build system relatively easy, if you understand it (see next point).
 
4. *Developing* the autotools build system is a PITA. There are a lot of 
details and basic understanding required in order to both make sense and use it 
effectively. Once everything works, it's *great* (point 1), but sometimes 
getting there takes a while. Also, fewer people are willing to help with it 
because of the overhead.
 
Pd is in some ways both a simple and a complex project to build. Simple in that 
C is easy to build anywhere and TCL just needs things in the right place. It's 
complex in that Pd builds and runs on a variety of platforms, each with it's 
own peculiarities.
 
The original makefile build system works relatively well for the simple cases 
while the autotools build system works for the complexities (while requiring 
complexity). The makefiles are straightforward and easy to understand at a loss 
in flexibility while ./configure et al are black boxes that support lots of 
configuration options and hopefully work most of the time.
 
When I did the overhaul last year, I went through and added documentation to 
the various Makefile.ams and the configure.ac  to help in understanding things, 
but I think that it's still down to IOhannes and I to do any sort of work on 
the setup as it is. I'm not sure if that is healthy in the long run.
 
I'm thinking now about about different approaches to simplify what is there:
 
1. non-recursive automake: a single large Makefile.am without the various files 
in subfolders. There are a number of advantages to this including build speed, 
putting things in one place, etc.
 
2. hybrid autoconf/makefile: If we want, we can use regular makefile rules in 
automake files or our own makefiles instead of automake and simply use the 
configuration variables for autoconf. This would allow for exposing more of the 
core build information in a readable way at the expense of perhaps higher 
maintenance.
 
The autotools are definitely useful but I admit can be a bit of a beast (but 
this guide helps a great deal: https://autotools.io/index.html). OTOH I would 
argue that *any* build system can be a beast, especially for a cross-platform 
project. In either case, I don't think we want to end up with a 
"non-understandable black box mess" and I'm thinking of ways to make things 
easy to work with for both Pd users *and* developers.
 


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and