Re: [PD] is GEM alive?

[IOhannes m zmölnig]

On 8/16/19 9:42 PM, Claude Heiland-Allen wrote:
> Debian package search reports

speaking of Debian:
$ apt install gem

gfmdsar
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] is GEM alive?

[Claude Heiland-Allen]

Hi Tim,

Which OS are you on?

On 16/08/2019 19:21, tim vets wrote:

It's been a while since I used Gem,
but in the past weeks I tried running it a few times without success.
(Pd0.49 as well as the latest and greatest 0.5)
Trying to compile from source I'm stuck at:

In file included from TextBaseFTGL.cpp:24:0:
TextBase.h:39:12: fatal error: FTFont.h: No such file or directory
 #  include "FTFont.h"
            ^~
compilation terminated.


Debian package search reports an FTFont.h in libftgl-dev [1]
With this installed `./autogen.sh && ./configure` from [2] outputs:

```
 used optional libraries:

  font-rendering : FTGL
 default font    :
```

Maybe the configure check is broken when FTGL is not installed?  Try 
installing libftgl-dev, and report back if this fixes it or otherwise.



Claude

[1] 
https://packages.debian.org/search?searchon=contents=FTFont.h=path=stable=any

[2] https://github.com/umlaeute/Gem

--
https://mathr.co.uk




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

[PD] is GEM alive?

[tim vets]

It's been a while since I used Gem,
but in the past weeks I tried running it a few times without success.
(Pd0.49 as well as the latest and greatest 0.5)
Trying to compile from source I'm stuck at:

In file included from TextBaseFTGL.cpp:24:0:
TextBase.h:39:12: fatal error: FTFont.h: No such file or directory
 #  include "FTFont.h"
^~
compilation terminated.

I couldn't find the information I need to overcome this so far...

I also noticed that [gemwin] has been replaced with an abstraction saying
"meant as a modular replacement for the internal [gemwin]
TODO: quite everything"

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

Re: [PD] Student Project Advice

[IOhannes m zmölnig]

Am 16. August 2019 17:15:51 MESZ schrieb Rick Snow :
>Hi Christof,
>
>Does anyone know why Jake can’t seem to sign up for the list?
>

i'll check when i'm back in office next week.
if not, ping me.


mfg.hft.fsl
IOhannes


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

Re: [PD] Student Project Advice

[Rick Snow]

Hi Christof,

Thanks so much for getting back to us (and so quickly).  This is very helpful 
for Jake.  I told him how quickly the PD community would respond and you did 
not disappoint.  We’ll continue to work based on your advice and will update 
when we are further along.

Does anyone know why Jake can’t seem to sign up for the list?

Cheers,
Rick



> On Aug 15, 2019, at 4:15 PM, Christof Ressi  wrote:
> 
> Hi Rick,
>  
> > Pd crashes every time a bang hits the object, which is what triggers the 
> > internal calculations, including reading the text files.
>  
> Actually, it should also crash when using the float inlets. The problem is 
> that his object contains a "struct date *mydate;" member which points to 
> nowhere. Accessing this pointer will of course lead to a segfault. It should 
> be a "struct date mydate;" instead.
>  
> Also, all the "t_atom mer[3]", "t_atom ven[3]", etc. members are only used in 
> trackingPlanets_bang, so they should be local variables.
>  
> Generally, I think he doesn't understand pointers and memory management very 
> well. Take this example:
>  
> double* coef1 = malloc(sizeof(double));
> double* coef2 = malloc(sizeof(double));
> double* coef3 = malloc(sizeof(double));
> struct term termi;
> termi.numTerm = getTermNum(line);
> readTermCoefs(line, coef1, coef2, coef3);
> termi.a = *coef1;
> termi.b = *coef2;
> termi.c = *coef3;
>  
> This should simply read:
>  
> struct term termi;
> termi.numTerm = getTermNum(line);
> readTermCoefs(line, , , );
>  
> Note in his original code, coef1, coef2, coef3 are never freed. In fact, his 
> code is full of those tiny memory leaks.
>  
> I don't want to sound too harsh but I think Jacob needs to first learn the 
> basics of the C programming language before attempting to write a Pd 
> external. There are some good books and tutorials with lots of practical 
> exerices. Also, he might want to show his code to a more experienced C 
> programmer (might be a teacher or colleague) to get some feedback.
>  
> Also, I highly recommend learning the very basics of a debugger to find out 
> where your program crashes. Assuming he's using GCC, it's enough to start Pd 
> in the debugger, e.g. "gdb --args pd ./mypatch.pd" -> "run", and after the 
> crash type "bt" to get the backtrace.
>  
> Best,
>  
> Christof
>  
> Gesendet: Donnerstag, 15. August 2019 um 22:28 Uhr
> Von: "Rick Snow" 
> An: pd-list@lists.iem.at
> Cc: "Gartenstein, Jacob P" 
> Betreff: [PD] Student Project Advice
> Hi all,
>  
> I have a student trying to sign up to the list and ask a question but he is 
> having some trouble being approved to this list.  I am pasting his question 
> below and will send any responses to him!  Thanks for any advice you might 
> have.  His email address is jgart...@tulane.edu 
>  
> From: Gartenstein, Jacob P
> Sent: Wednesday, August 14, 2019 12:50 AM
> To: pd-list@lists.iem.at   >
> Subject: Questions about External 
>  
> Dear Pd Community - 
>  
> I'm trying to create an object, via a pd external, which takes in several 
> parameters, does internal calculations, and outputs several lists of floats.  
> Part of the internal calculation process includes reading thousands of lines 
> of equation coefficients from text documents.  These coefficients, along with 
> the input parameters, are necessary to perform the internal calculations.  
>  
> I've linked the pd external, entitled trackingPlanets, which creates in pd 
> but doesn't perform any of the desired functionality.  Pd crashes every time 
> a bang hits the object, which is what triggers the internal calculations, 
> including reading the text files.  Through the course of some tests, I've 
> discovered that the text file reading functions cause pd to crash. 
>  
> My questions:
>  
> Is there some method to internally read data from text files in pd?
>  
> Are the internal calculations too much and causing pd to crash?
>  
> Are there more efficient methods of reaching my desired functionality that 
> may help pd run more smoothly?
>  
> Thanks in advance for the help,
>  
> Jake Gartenstein 
>  
> Materials:
> https://drive.google.com/drive/folders/1KYB9GyP31I9tGfwFnY7ctfUH24qvClXa?usp=sharing
>  
> 
>  
> ___ 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 -> 

Re: [PD] [PD-announce] pd 0.50-0 test1 released - zooming issues

[Jean-Yves Gratius]

There are some troubles with patch-editing features while zooming=2, 
that did not occur with pd v0.49


(mouse cursor position and created objects position are not consistent 
with zoom=2)


As I am addicted with this zooming feature, I proposed some fixes in a 
new P.R.


https://github.com/pure-data/pure-data/pull/733





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