Re: [PD-dev] Filter PD debug output in Powershell

[Henri Augusto Bisognini]

Indeed! When using 2>&1 the filtered output comes out as errors (black bkg and 
red text). Is there anyway to correct that?



De: Pd-dev  em nome de Christof Ressi 

Enviado: domingo, 24 de maio de 2020 18:30
Para: pd-dev 
Assunto: Re: [PD-dev] Filter PD debug output in Powershell


Hi,


your problem is that Pd writes the messages to stderr, but the pipe operator 
reads from stdout. You can redirect stderr to stdout with "2>&1" before 
filtering the output (should also work in modern Powershell).


Christof

On 24.05.2020 22:50, Henri Augusto Bisognini wrote:
Hey list! Hope you're all well!

I'm debugging communication between the core and the gui with "-d 3"  and i 
want to filter out all those mouse "motion" and "coords" events in PowerShell.

I'm trying

./pd.com -d 3  | ? {$_ -notlike "*motion*"}

But it doesn't work. Interestingly this one does work:

"abc", ".x695480 motion 208.0 124.0 0;", "efg" | ? {$_ -notlike "*motion*"}

Whats wrong?

Cheers,
Henri.




___
Pd-dev mailing list
Pd-dev@lists.iem.at<mailto:Pd-dev@lists.iem.at>
https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Filter PD debug output in Powershell

[Henri Augusto Bisognini]

Hey list! Hope you're all well!

I'm debugging communication between the core and the gui with "-d 3"  and i 
want to filter out all those mouse "motion" and "coords" events in PowerShell.

I'm trying

./pd.com -d 3  | ? {$_ -notlike "*motion*"}

But it doesn't work. Interestingly this one does work:

"abc", ".x695480 motion 208.0 124.0 0;", "efg" | ? {$_ -notlike "*motion*"}

Whats wrong?

Cheers,
Henri.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Keyboard-independent way of detecting shift+digits

[Henri Augusto Bisognini]

Hi list, how are you? Hope you're all well during those difficult times.

Still working on the keyboard navigation 
prototype and i'm facing what 
is not a PD-specific challenge but still you guys might be able to help solving 
the issue or maybe suggesting a workaround.

stack overflow: Keyboard-independent way of detecting 
shift+digits

Cheers,
Henri.


___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PD-specific tips for compiling faster on Windows

[Henri Augusto Bisognini]

Thanks a lot for your help, guys.

To be honest i was running make app (msw-app.sh, actually) everytime haha

As a newcomer its been hard wrapping my head around everything, especially 
since i'm used to interpreted languages - and Java, which is, well, Java.

(Christof, those C++17 conference videos you've sent me still gives me the 
nightmares)

So definitely i would say a better detailed dev guide would be great heh  We 
even discussed this 
briefly<https://lists.puredata.info/pipermail/pd-list/2019-10/126180.html> in 
the list.

If i had the knowledge i would definitely help writing it - but i can help 
reviewing/testing.

Anyway thanks again for your tips. They will save me lots of time!

Cheers,
Henri.



De: Dan Wilcox 
Enviado: terça-feira, 21 de abril de 2020 11:50
Para: Christof Ressi ; Henri Augusto Bisognini 

Cc: pd-dev 
Assunto: Re: [PD-dev] PD-specific tips for compiling faster on Windows

Actually, 1-2 minutes is pretty good! Before Christof helped with improving the 
build on Windows, it was more into the 10 minute range due to the layout and 
compilation order of the files.

Christof is right in that if you are just testing smaller changes, you can just 
rebuild the core and put the compiled file into the bin folder to run it 
without having to rebuild the whole thing. I also do this on macOS where I 
build the Pd core and simply copy the updated pd executable into the .app 
bundle without rebuilding the entire bundle each time.

Maybe we should include some dev / debug tips and tricks about this to the 
INSTALL.txt?

There has been interest for using CMake for libpd, so I could see that as a 
companion method to build Pd but not a replacement for autotools IMO. Then we 
would have 3 methods to build it, yeah! :P In any case, as long as something 
like this is maintained, it's all good as Pd should be easy to compile on it's 
platforms.

On Apr 21, 2020, at 12:00 PM, 
pd-dev-requ...@lists.iem.at<mailto:pd-dev-requ...@lists.iem.at> wrote:

Date: Tue, 21 Apr 2020 10:24:54 +0200
From: Christof Ressi mailto:i...@christofressi.com>>
To: pd-dev@lists.iem.at<mailto:pd-dev@lists.iem.at>
Subject: Re: [PD-dev] PD-specific tips for compiling faster on Windows
Message-ID: 
<4426262d-2274-567a-8e3c-fd2935e75...@christofressi.com<mailto:4426262d-2274-567a-8e3c-fd2935e75...@christofressi.com>>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

Autotools (especially libtool) is very slow on MinGW. On my system,
compiling the /extra externals takes significantly longer than compiling
the actual Pd application, only because of libtool.


If you want to get faster build times, rewrite the build system in CMake
and compile with MSVC :-)


How often do you need to recompile whole Pd? Usually, you just change
1-2 files and this should compile and link rather quickly. "make app" is
also slow (again, because of libtool). Usually, I only run "make app"
once and then just copy pd.dll into the Pd folder on the command line
(assuming you only make changes to the core):


cp ./src/pd.dll ./pd-0.50.2/bin


Christof


Dan Wilcox
@danomatika<http://twitter.com/danomatika>
danomatika.com<http://danomatika.com>
robotcowboy.com<http://robotcowboy.com>



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] PD-specific tips for compiling faster on Windows

[Henri Augusto Bisognini]

Hi list!

I'm using the usual build tools (as in INSTALL.txt) for compiling PD. Builds 
here can take several minutes for completion.

I know that compiling times on windows are generally slower than Linux and 
sometimes OSX. But i wonder if there is any pd-specific tips on optimizing 
compile time on Windows.

Cheers,
Henri
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] MSYS2 Portable and PD

[Henri Augusto Bisognini]

Hey list! How are you?

I'm trying to compile PD in a Win 10 computer using MSYS2 portable.
I've did it exactly  the same steps as when I've installed MSYS2 on my Win 7 pc.

When running ./configure I've got an error

configure: error: no acceptable C compiler found in $PATH

"Makes sense", i think. This is an portable version after all. So I've added 
D:\software\msys2\mingw64\bin to the Win 10 %PATH% variable.

Got the same error.

Then I've added d/software/msys2/mingw64/bin to MSYS2's $PATH and still got the 
same error.

To add to $PATH I've used :
export PATH=$PATH:d/software/msys2/mingw64/bin

Anybody have any clues in what is going wrong?


Full output of ./configure :

configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
configure: iPhone SDK only available for arm-apple-darwin hosts, skipping tests
configure: Android SDK only available for arm-linux hosts, skipping tests
checking for as... no
checking for dlltool... no
checking for objdump... no
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in 
`/e/Users/User/Desktop/Software/PureData/pure-data-0.49-0-kbd':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] MSYS2 Portable and PD

[Henri Augusto Bisognini]

Ok, got it.

I was inadvertently opening the msys2.exe instead of mingw64.exe


De: Henri Augusto Bisognini
Enviado: quinta-feira, 20 de fevereiro de 2020 14:57
Para: pd-dev@lists.iem.at 
Assunto: MSYS2 Portable and PD

Hey list! How are you?

I'm trying to compile PD in a Win 10 computer using MSYS2 portable.
I've did it exactly  the same steps as when I've installed MSYS2 on my Win 7 pc.

When running ./configure I've got an error

configure: error: no acceptable C compiler found in $PATH

"Makes sense", i think. This is an portable version after all. So I've added 
D:\software\msys2\mingw64\bin to the Win 10 %PATH% variable.

Got the same error.

Then I've added d/software/msys2/mingw64/bin to MSYS2's $PATH and still got the 
same error.

To add to $PATH I've used :
export PATH=$PATH:d/software/msys2/mingw64/bin

Anybody have any clues in what is going wrong?


Full output of ./configure :

configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-msys
checking host system type... x86_64-pc-msys
configure: iPhone SDK only available for arm-apple-darwin hosts, skipping tests
configure: Android SDK only available for arm-linux hosts, skipping tests
checking for as... no
checking for dlltool... no
checking for objdump... no
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in 
`/e/Users/User/Desktop/Software/PureData/pure-data-0.49-0-kbd':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Bit fields in t_editor

[Henri Augusto Bisognini]

Quick C question: i was taking a look at struct _editor and I've noticed that 
the bitfields sum up to  6 with no (2 bits) padding for alignment.

typedef struct _editor
{
t_updateheader e_upd;   /* update header structure */
[...]
unsigned int e_onmotion: 3; /* action to take on motion */
unsigned int e_lastmoved: 1;/* one if mouse has moved since click */
unsigned int e_textdirty: 1;/* one if e_textedfor has changed */
unsigned int e_selectedline: 1; /* one if a line is selected */
t_clock *e_clock;   /* clock to filter GUI move messages */
int e_xnew; /* xpos for next move event */
[...]

} t_editor;

All the resources I've found on google used some padding (either manually or 
with a zero value).

My guess here is that since the next member is not a bit field then the 
compiler will align it for you. Is that right?

Cheers,
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Hi!

I have a question regarding how can i use the pimpl idiom in the kbd navigation 
case.
The editor private members will be defined in g_editor.c.
But since i'm moving the core kbd navigation stuff to it's own file 
(g_kbdnav.c) i must have a way of accessing this t_kbdnav struct on that file.

Currently i've used the solution (example below) of implementing a 
canvas_getkbdnav(t_canvas *x) function on g_editor.c that returns a pointer to 
it's t_kbdnav struct.

Is this okay/good? Why?

Note:
I could make canvas_getkbdnav(t_canvas *x) static and pass a t_kbdnav pointer 
as a parameter from g_editor to the kbdnav stuff. The problem is that i also i 
need to call some kbdnav function from the iemgui files (g_toggle.c, 
g_hslider.c, etc) because they have custom drawing functions that need to call 
some kbdnav logic to draw the in/outlet selection.



--g_canvas.h--

typedef struct _editor {
...
void *e_privatedata;
} t_editor;

--g_editor.c--

typedef struct _editor_private {
#ifdef HAVE_KEYBOARDNAV
t_kbdnav kbdnav;
#endif
} t_editor_private;

t_kbdnav* canvas_getkbdnav(t_canvas *x)
{
...
}

--g_kbdnav.h--

EXTERN t_kbdnav* canvas_getkbdnav(t_canvas *x);

--g_kbdnav.c--

void kbdnav_somefunction(t_canvas *x)
{
t_kbdnav *kbdnav = canvas_getkbdnav(x);
...
}


Cheers,
Henri.




De: Christof Ressi 
Enviado: terça-feira, 16 de julho de 2019 14:32
Para: Henri Augusto Bisognini 
Cc: pd-dev@lists.iem.at 
Assunto: Aw: Re: [PD-dev] First complete keyboard navigation prototype

Hi,

> But it appears that actually the size of the struct is deduced while 
> compiling. So if you write an external it is going to think the canvas struct 
> is the same size as it was in the pd header files that were used during 
> compilation.

exactly.

> When using the pointer to implementation idiom, wouldn't the pointer itself 
> change the size of the struct?

yes, it will

> You've said something about that not being a problem when you add it as the 
> last member of the struct but i don't understand why and how that would work.

usually, externals shouldn't care about the *size* the t_editor struct (at 
least I can't think of any use case), so you can get away with adding new 
fields at the end (although it's certainly not recommended). Note that those 
headers aren't really public anyway!

However, appending fields conditionally can lead to problems:

struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
};

Now let's say we need to add another member:

struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
in b;
};

If the host compiles with FOO_EX defined and the client doesn't, the latter 
will assume a wrong offset for 'b'.

The solution is to add a field for private data *once*. The advantage is that 
a) we can hide the private data and b) we can extend it without worrying about 
compatibility:

struct Foo {
   int a;
   PrivateFoo *p;
};

We can still add public members if needed:

struct Foo {
int a;
void *private;
int b;
};

'private' points to a private data structure that is not be visible to clients. 
There you can conditionally enable members without problems:

struct PrivateFoo {
#ifdef USE_BAR
struct MyFeature feature;
#endif
};

MyFeature could be in a seperate source file together with your methods and it 
only gets compiled when needed.

Again, have a look at the "t_canvas_private" struct and the "gl_privatedata" 
member of "_glist" (aka "t_canvas") and do the same for "_editor", e.g.:

in g_canvas.h:

typedef struct _editor {
...
void *e_privatedata;
} t_editor;

in g_editor.c:

#ifdef HAVE_KEYBOARDNAV
#include "g_keyboardnav.h"
#endif

typedef struct _editor_private {
#ifdef HAVE_KEYBOARDNAV
t_keyboardnav keyboardnav;
#endif
} t_editor_private;

the "t_keyboardnav" struct is defined in "g_keyboardnav.h" and its methods 
implemented in "g_keyboardnav.c". Both only get compiled when needed.

Hope this makes sense.

Christof

Gesendet: Dienstag, 16. Juli 2019 um 16:51 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: Re: [PD-dev] First complete keyboard navigation prototype
Okay, just help me check if i got it right.

At first i was thinking that when externals, for any reason, used the size of 
the canvas struct (or any other) it would do so in real time. Like calling 
sizeof() and stuff.

But it appears that actually the size of the struct is deduced while compiling. 
So if you write an external it is going to think the canvas struct is the same 
size as it was in the pd header files that were used during compilation.

Is that it?

I don't think i quite get something. When using the pointer to implementation 
idiom, wouldn

Re: [PD-dev] How to use a debugger with PD on Windows

[Henri Augusto Bisognini]

Thanks, Christof!

I'm so used to IDEs I've totally missed it.

Henri


De: Christof Ressi 
Enviado: segunda-feira, 7 de outubro de 2019 11:43
Para: Henri Augusto Bisognini ; pd-dev 

Assunto: Aw: [PD-dev] How to use a debugger with PD on Windows

With MSys2 you already have GDB installed. Just do:

> gdb --args pd [flags]
> run

when you get a segfault, type "bt" to get a backtrace :-). If you want to use 
breakpoints and stuff, just read the GDB manual.

Christof

Gesendet: Montag, 07. Oktober 2019 um 15:45 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: [PD-dev] How to use a debugger with PD on Windows
Hi list!

I'm looking for some direction on how to set a debugger with Pure Data. I'm on 
windows using MinGW (MSys2) as described in 
INSTALL.TXT<https://github.com/pure-data/pure-data/blob/master/INSTALL.txt>.

Cheers,
Henri.
___ Pd-dev mailing list 
Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] How to use a debugger with PD on Windows

[Henri Augusto Bisognini]

Hi list!

I'm looking for some direction on how to set a debugger with Pure Data. I'm on 
windows using MinGW (MSys2) as described in 
INSTALL.TXT.

Cheers,
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] keyboard navigation: #ifdefs

[Henri Augusto Bisognini]

Hey list!

I've been trying to isolate the keyboard navigation as much as i could since 
you guys said it should be compiled optionally.

While a lot of stuff could be moved to it's own file (g_kbdnav.c) there are 
also a lot of code that need to be in the middle of pd's core functions.

For example, here is the modified canvas_obj() function on the g_text.c to not 
cinlude the code related to keyboard navigation:

https://gist.github.com/HenriAugusto/e417c8f269ad10df2dc3359b907ea588

It's not as pretty as it could be but it's readable (if your editor has code 
folding you can just hide the relevant lines to see what the code looks like, 
for example).

Is there a better way to do this?

Cheers,
Henri.


Just in case, those are examples of some other modified core functions:

in g_text.c

glist_drawiofor(...) - draws a rectangle around the selected in/outlet
canvas_howputnew(...) - position a new object exactly below/above to selected 
in/outlet

in g_canvas.c

canvas_drawlines(...) - draws lines in different colors while navigating 
through connections
canvas_map(...) - draws each object's index if the user has asked so (useful 
for the goto functionality)



De: Christof Ressi 
Enviado: terça-feira, 16 de julho de 2019 14:32
Para: Henri Augusto Bisognini 
Cc: pd-dev@lists.iem.at 
Assunto: Aw: Re: [PD-dev] First complete keyboard navigation prototype

Hi,

> But it appears that actually the size of the struct is deduced while 
> compiling. So if you write an external it is going to think the canvas struct 
> is the same size as it was in the pd header files that were used during 
> compilation.

exactly.

> When using the pointer to implementation idiom, wouldn't the pointer itself 
> change the size of the struct?

yes, it will

> You've said something about that not being a problem when you add it as the 
> last member of the struct but i don't understand why and how that would work.

usually, externals shouldn't care about the *size* the t_editor struct (at 
least I can't think of any use case), so you can get away with adding new 
fields at the end (although it's certainly not recommended). Note that those 
headers aren't really public anyway!

However, appending fields conditionally can lead to problems:

struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
};

Now let's say we need to add another member:

struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
in b;
};

If the host compiles with FOO_EX defined and the client doesn't, the latter 
will assume a wrong offset for 'b'.

The solution is to add a field for private data *once*. The advantage is that 
a) we can hide the private data and b) we can extend it without worrying about 
compatibility:

struct Foo {
   int a;
   PrivateFoo *p;
};

We can still add public members if needed:

struct Foo {
int a;
void *private;
int b;
};

'private' points to a private data structure that is not be visible to clients. 
There you can conditionally enable members without problems:

struct PrivateFoo {
#ifdef USE_BAR
struct MyFeature feature;
#endif
};

MyFeature could be in a seperate source file together with your methods and it 
only gets compiled when needed.

Again, have a look at the "t_canvas_private" struct and the "gl_privatedata" 
member of "_glist" (aka "t_canvas") and do the same for "_editor", e.g.:

in g_canvas.h:

typedef struct _editor {
...
void *e_privatedata;
} t_editor;

in g_editor.c:

#ifdef HAVE_KEYBOARDNAV
#include "g_keyboardnav.h"
#endif

typedef struct _editor_private {
#ifdef HAVE_KEYBOARDNAV
t_keyboardnav keyboardnav;
#endif
} t_editor_private;

the "t_keyboardnav" struct is defined in "g_keyboardnav.h" and its methods 
implemented in "g_keyboardnav.c". Both only get compiled when needed.

Hope this makes sense.

Christof
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Thanks a lot for your input Christof!

If i may let me ask a couple of question:

1) I've been wandering through the sources and i'm not sure: where should i put 
the "#def HAVE_KEYBOARDNAV"? Also this value will be set manually in the code 
or is there anyway to set it via some config file/some other way?

___

2) Also i've put a big portion of the code in a g_kbdnav.c file a long with 
it's forward declarations in g_kbdnav.h.

Why it was in g_editor? Because it uses canvas_connect_with_undo, for example, 
which is static.

What should i do? Change those methods so they're not static anymore?

Or maybe put a "helper function" inside g_editor.c?

in g_editor.c:

void kbdnav_connect_with_undo(t_canvas *x, t_float index1, t_float outno, 
t_float index2, t_float inno){
connect_with_undo(x, index1,outno, index2, inno);
}

in g_kbdnav.c:

[...]
kbdnav_connect_with_undo(...)
[...]


Or should i do something else?
___

By the way i wanted to hear more from you guys about the experience when trying 
the kbdnav prototype! :)
Almost no one commented.

Best,
Henri.


From: Christof Ressi 

Hi,

> But it appears that actually the size of the struct is deduced while 
> compiling. So if you write an external it is going to think the canvas struct 
> is the same size as it was in the pd header files that were used during 
> compilation.

exactly.

> When using the pointer to implementation idiom, wouldn't the pointer itself 
> change the size of the struct?

yes, it will

> You've said something about that not being a problem when you add it as the 
> last member of the struct but i don't understand why and how that would work.

usually, externals shouldn't care about the *size* the t_editor struct (at 
least I can't think of any use case), so you can get away with adding new 
fields at the end (although it's certainly not recommended). Note that those 
headers aren't really public anyway!

However, appending fields conditionally can lead to problems:

struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
};

Now let's say we need to add another member:

struct Foo {
int a;
#ifdef FOO_EX
int c;
#endif
in b;
};

If the host compiles with FOO_EX defined and the client doesn't, the latter 
will assume a wrong offset for 'b'.

The solution is to add a field for private data *once*. The advantage is that 
a) we can hide the private data and b) we can extend it without worrying about 
compatibility:

struct Foo {
   int a;
   PrivateFoo *p;
};

We can still add public members if needed:

struct Foo {
int a;
void *private;
int b;
};

'private' points to a private data structure that is not be visible to clients. 
There you can conditionally enable members without problems:

struct PrivateFoo {
#ifdef USE_BAR
struct MyFeature feature;
#endif
};

MyFeature could be in a seperate source file together with your methods and it 
only gets compiled when needed.

Again, have a look at the "t_canvas_private" struct and the "gl_privatedata" 
member of "_glist" (aka "t_canvas") and do the same for "_editor", e.g.:

in g_canvas.h:

typedef struct _editor {
...
void *e_privatedata;
} t_editor;

in g_editor.c:

#ifdef HAVE_KEYBOARDNAV
#include "g_keyboardnav.h"
#endif

typedef struct _editor_private {
#ifdef HAVE_KEYBOARDNAV
t_keyboardnav keyboardnav;
#endif
} t_editor_private;

the "t_keyboardnav" struct is defined in "g_keyboardnav.h" and its methods 
implemented in "g_keyboardnav.c". Both only get compiled when needed.

Hope this makes sense.

Christof

Gesendet: Dienstag, 16. Juli 2019 um 16:51 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: Re: [PD-dev] First complete keyboard navigation prototype
Okay, just help me check if i got it right.

At first i was thinking that when externals, for any reason, used the size of 
the canvas struct (or any other) it would do so in real time. Like calling 
sizeof() and stuff.

But it appears that actually the size of the struct is deduced while compiling. 
So if you write an external it is going to think the canvas struct is the same 
size as it was in the pd header files that were used during compilation.

Is that it?

I don't think i quite get something. When using the pointer to implementation 
idiom, wouldn't the pointer itself change the size of the struct? You've said 
something about that not being a problem when you add it as the last member of 
the struct but i don't understand why and how that would work.

(I don't have a formal background on programming so forgive me if thats obvious 
or something.)



De: Christof Ressi 
Enviado: sábado, 15 de junho de 2019 17:11
Para: Henri Augusto Bisognini
Cc: pd-dev@lists.iem.at
Assunto: Aw: Re: [PD-dev] First complete keyboard

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Okay, just help me check if i got it right.

At first i was thinking that when externals, for any reason, used the size of 
the canvas struct (or any other) it would do so in real time. Like calling 
sizeof() and stuff.

But it appears that actually the size of the struct is deduced while compiling. 
So if you write an external it is going to think the canvas struct is the same 
size as it was in the pd header files that were used during compilation.

Is that it?

I don't think i quite get something. When using the pointer to implementation 
idiom, wouldn't the pointer itself change the size of the struct? You've said 
something about that not being a problem when you add it as the last member of 
the struct but i don't understand why and how that would work.

(I don't have a formal background on programming so forgive me if thats obvious 
or something.)


De: Christof Ressi 
Enviado: sábado, 15 de junho de 2019 17:11
Para: Henri Augusto Bisognini
Cc: pd-dev@lists.iem.at
Assunto: Aw: Re: [PD-dev] First complete keyboard navigation prototype

Hi, as IOhannes said, "g_canvas.h" is semi-public in a sense that some 
externals use it (e.g. iemguts). So unless it is absolutely necessary, we 
should avoid breaking binary compatibility.


If the e_kbdnav member is only conditionally enabled with an #ifdef, existing 
externals (or those not compiled with key-nav-support) will see a different 
size of t_editor. This is not much of a problem as long as e_kbdnav is the last 
member of t_editor, but as soon as we add another member, we might run into 
problems, since this last field will be at a different offset.

I think the solution is simple: just add a "void *e_private" member which 
points to some private data where we can put all stuff which we don't want to 
expose the header. (This is called the "PIMPL idiom"). e_kbdnav would be the 
first member of such private data.

IOhannes actually did this with the "gl_privatedata" member in t_canvas to hide 
the undo queue implemention.  The "t_canvas_private" struct currently only has 
a "t_undo" member but it's possible to add/remove/rearrange members at will 
without having to think about binary compatibility issues because it's not in a 
header file.

Christof
Gesendet: Samstag, 15. Juni 2019 um 19:58 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: Re: [PD-dev] First complete keyboard navigation prototype
Please excuse my ignorance on that matter but could you give me a brief 
explanation of the problem at hand?



De: Pd-dev  em nome de IOhannes m zmölnig 

Enviado: sexta-feira, 14 de junho de 2019 04:37
Para: pd-dev@lists.iem.at
Assunto: Re: [PD-dev] First complete keyboard navigation prototype

On 6/13/19 7:34 PM, Henri Augusto Bisognini wrote:
> Also, in g_canvas.h, inside the "struct _editor" there is a "struct _kbdnav" 
> member. This is the struct that contains the data used in the keyboard 
> navigation.
>

i haven't looked at the actual code, but what you describe here, is that
you are actually changing the size of a quasi-public struct and thus the
memory layout as presented to externals.

which means that a version of Pd that has the keyboard-navigation
enabled is (partly) *binary-incompatible* with a version of Pd that does
not have the keyboard-navigation enabled.

bummer :-(

gfmadr
IOhannes

___ Pd-dev mailing list 
Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Please excuse my ignorance on that matter but could you give me a brief 
explanation of the problem at hand?


De: Pd-dev  em nome de IOhannes m zmölnig 

Enviado: sexta-feira, 14 de junho de 2019 04:37
Para: pd-dev@lists.iem.at
Assunto: Re: [PD-dev] First complete keyboard navigation prototype

On 6/13/19 7:34 PM, Henri Augusto Bisognini wrote:
> Also, in g_canvas.h, inside the "struct _editor" there is a "struct _kbdnav" 
> member. This is the struct that contains the data used in the keyboard 
> navigation.
>

i haven't looked at the actual code, but what you describe here, is that
you are actually changing the size of a quasi-public struct and thus the
memory layout as presented to externals.

which means that a version of Pd that has the keyboard-navigation
enabled is (partly) *binary-incompatible* with a version of Pd that does
not have the keyboard-navigation enabled.

bummer :-(

gfmadr
IOhannes

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

I could change it to separate it from the rest. But probably i'll need some 
directions as i'm a newbie.

Some stuff is already separated such as the hotkey handling which is done in 
kbdnav_key<https://github.com/HenriAugusto/pure-data/blob/f5c39cb5cd7ebc101b0b3d9dcde28491b2093b57/src/g_editor.c#L5025>
 instead of canvas_key (which is already very long).

But there is stuff like the drawing of the rectangles to indicate which 
in/outlet is selected for example, which is done in 
glist_drawiofor<https://github.com/HenriAugusto/pure-data/blob/f5c39cb5cd7ebc101b0b3d9dcde28491b2093b57/src/g_text.c#L1365>
 inside  g_texc.c.

Also, in g_canvas.h, inside the "struct _editor" there is a "struct _kbdnav" 
member. This is the struct that contains the data used in the keyboard 
navigation.

So how one should go to keep everything optional?
Using preprocessor #if's to include/exclude code during compilation?


De: Miller Puckette 
Enviado: quarta-feira, 12 de junho de 2019 00:48
Para: Dan Wilcox
Cc: Henri Augusto Bisognini; pd-dev
Assunto: Re: [PD-dev] First complete keyboard navigation prototype

I agree - I haven't looked at the code but if it can fit easily into Pd's
source tree as a run-time option this would be worth adding.

cheers
M

On Mon, Jun 10, 2019 at 01:59:35PM +0200, Dan Wilcox wrote:
> *Not really feedback, but just a general response.*
>
> One thing I would suggest would be to make this an optional feature in some 
> way. Maybe we can work together with IOhannes and Christof to propose changes 
> to the Pd sources to allow for adding in this kind of functionality without 
> *requiring* it to be built into the core itself. I have been thinking of 
> these kinds of approaches since I see this being a greta feature for the GUI 
> but basically unused for something like libpd. In the latter case, I'd like 
> to simply not compile it and the easiest way would if the main functionality 
> is in a separate set of files that can be left out.
>
> This might be a process that has to happen later on, but something to think 
> of for now in order to balance the addition of new features while maintaining 
> the possibility for a fast, slim core.
>
> > On Jun 10, 2019, at 10:30 AM, pd-dev-requ...@lists.iem.at wrote:
> >
> > Date: Sun, 9 Jun 2019 19:16:36 +
> > From: Henri Augusto Bisognini  > <mailto:msndohe...@hotmail.com>>
> > To: "pd-dev@lists.iem.at <mailto:pd-dev@lists.iem.at>"  > <mailto:pd-dev@lists.iem.at>>
> > Subject: Re: [PD-dev] First complete keyboard navigation prototype
> > Message-ID:
> >  
> >  >  
> > <mailto:cp2pr80mb0386c0d2c66d1ce34f458be3cc...@cp2pr80mb0386.lamprd80.prod.outlook.com>>
> >
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Thanks Christof! Indeed it's already been very nice to use it during my 
> > tests.
> >
> > I'l probably wrap up a small file containing some basic infos about how 
> > everything works to make it easier for more people to modify the code and 
> > test ideas.
>
> 
> Dan Wilcox
> @danomatika <http://twitter.com/danomatika>
> danomatika.com <http://danomatika.com/>
> robotcowboy.com <http://robotcowboy.com/>
>
>
>

> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Lucas Cordiviola wrote:

> Right, i could finish the build.
>
> Here on my linux box (Debian9 Xfce) everything is working except the < 
ctrl+'> (control + single quote) to enter the "canvas message console". I can 
enter it as explained in > "connecting_with_the_canvas_msg_console".
>
> Feature request:
>
> I found it difficult to see which cable is selected.
> I suggest making the selected cable "Thicker" or something that makes it 
more visually obvious.



About the hotkey: Oh, there was an typo on the help patch! It is really shift+'

(in reality the hotkey is bind to "quotedbl" in "pd_bindings.tcl", hence the 
shift+single quote)

About the cables: yeah, i've also found it difficult. I've tought about making 
it thicker but i was afraid it would make some confusion with signal cables. 
I've also thought about using different colors but since PD uses black (+gray), 
white and blue i've avoided, for now, using other colors.

When cycling between more than one cable I've tried to display the selected 
cable in blue, making the non-selected cables gray. It helps a little bit but i 
still think we need some that highlights it better.

Some ideas up for discussion (in no particular order)

- Using green to make it more contrasting with the rest.
- Making the line thicker and also green to avoid confusion with signal chords.
- Making the line thicker and using a dashed pattern
- Displaying like with the normal black fill but with an blue outline. (also it 
would be thicker as a result)

There is one option that always struck me as something that would be nice that 
is animating stuff to make them easier to see. But nothing in PD is animated so 
far so right know i'm considering the other options.

What do you think?
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Thanks Christof! Indeed it's already been very nice to use it during my tests.

I'l probably wrap up a small file containing some basic infos about how 
everything works to make it easier for more people to modify the code and test 
ideas.

Cheers,
Henri.


De: Christof Ressi 
Enviado: sábado, 8 de junho de 2019 08:35
Para: Henri Augusto Bisognini; Pd-List
Assunto: Aw: [PD-dev] First complete keyboard navigation prototype

Hi, this looks like wonderful! I'll try it out in a couple of days and give 
feedback. I can also help with code if needed.

My biggest issue with visual programming is the amount of mouse interaction 
needed in contrast to text based programming (especially when sitting in a 
shaky ÖBB-train with a tiny laptop). A keyboard workflow like yours could be 
extremely useful for power users.

Christof
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Sorry, it seems that i've uploaded the wrong "g_text.c" version to the kbd_nav 
branch. I should be fixed now.


De: Lucas Cordiviola 
Enviado: sábado, 8 de junho de 2019 01:10
Para: Henri Augusto Bisognini; pd-dev@lists.iem.at
Assunto: Re: [PD-dev] First complete keyboard navigation prototype


When trying to build on Debian I get this errors:



''


g_text.c: In function ‘canvas_howputnew’:
g_text.c:166:40: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( x->gl_editor->e_kbdnav.kn_navigating && 
x->gl_editor->e_kbdnav.kn_ioindex > 0 ){
^
g_text.c: In function ‘canvas_obj’:
g_text.c:237:41: error: ‘struct _kbdnav’ has no member named ‘kn_navigating’
 if ( gl->gl_editor->e_kbdnav.kn_navigating && 
gl->gl_editor->e_kbdnav.kn_ioindex != 0 ){
 ^
g_text.c: At top level:
cc1: warning: unrecognized command line option ‘-Wno-format-truncation’
cc1: warning: unrecognized command line option ‘-Wno-stringop-truncation’
cc1: warning: unrecognized command line option ‘-Wno-cast-function-type’


''

Mensaje telepatico asistido por maquinas.

On 6/7/19 11:52 PM, Henri Augusto Bisognini wrote:
Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.



N�n�r)em�h�yhiם�w^���
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] First complete keyboard navigation prototype

[Henri Augusto Bisognini]

Hi!

I've finally managed to get time to finish a prototype for a keyboard 
navigation interface. I mixed some ideas i had with some I've seen in Desire 
Data's old screenshot gallery (http://artengine.ca/desiredata/).

I've recorded some gifs to demonstrate it. (https://imgur.com/gallery/WSB40P7). 
It shows me using the help patch (which i've put in 
7.stuff/keyboard.navigation). You can read about which keys to use in the 
comments.

The source can be found on my GitHub, on the kbd_nav branch 
(https://github.com/HenriAugusto/pure-data/tree/kbd_nav)

Basically I've wanted to try:

- navigating through objects/inelts connection with ctrl+arrows (cmd+arrows on 
Mac)
- automatically positioning new objects according to selected inlet/outlet
- a console bar to send messages to the focused patch
- ability to display each object index (to be used with the functionalities 
below)
- a new "goto" canvas message to select any object in the patch
- a "magnetic connector" that connects the selected in/outlet to the nearest 
ins/outs
- a "digit connectors" that displays indexes 0 to 9 for the 10 nearest possible 
connections. Just press the number and it will connect it for you
- pd can automatically fill for you a "connect" message in the console 
containing the info for the selected inlet/outlet. It will even select for you 
the part you need to fill
- You can click objects with shift+enter. Mostly useful for sending bangs and 
opening subpatches/abstractions

Everything is intended to be as minimal as possible and very easy to use. I 
wish to propose we study including it in vanilla.

Well, what do you guys think?

This is my first time working on a project this big so help me out if i did 
anything incorrectly. I've been testing the major functions on Win for a while 
now but couldn't test on mac/linux.

Cheers,
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Code responsible for calling canvas_reselect

[Henri Augusto Bisognini]

When i use PD (Win 7) i can select an object and hit Ctrl+Enter to start/stop 
editing that object's text.

I can't seem to find the code responsible for that behavior.

Runningpd with the debug flag i can see that the gui sends a "$canvasname 
reselect" message to the patch (which is bound to "canvas_reselect" in 
"g_editor.c").

I've tried searching "reselect" and "Return" (case sensitive) for all the 
sources, checked pd_bindings.tcl but could find it.

Where and how exactly this reselect messages are sent from the gui?

Cheers,
Henri.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [PD] Keyboard patching

[Henri Augusto Bisognini]

On 11/24/18 6:41 PM, Henri Augusto Bisognini wrote:
> Hi PD list!
>
> I have an idea for a "keyboard patching" feature for PD

On 11/24/18 6:41 PM, IOhannes wrote:
you might want to look for the ideas matju (mathieu bouchard) had about
this back in the days (i remember a presentation at Pd~con in montreal,
together with chun lee).

Hi

Thanks a lot for pointing that out. The 
article<http://artengine.ca/~catalogue-pd/18-Lee-Bouchard.pdf> contains a lot 
of interesting ideas. Also upon searching for the 
DesireData<http://artengine.ca/desiredata/> implementation he mentioned on a 
footnote and looking at the screenshot gallery you can see even more features 
than described in the article. Too bad the project seems abandoned since 2010 :(


1. I really like the console idea. Indeed it is something that would not stand 
in the way of newcommers but could be very very useful for experienced users.

If you think about it, we kind of already can send commands to canvases by 
using [namecanvas] and the Message dialog heh. A console would send the 
commands to the right canvas for you. More on that below.


2. I don't like the 45 degrees/tile navigating method. It is not precise 
enough. In the current keyboard navigation 
prototype<https://www.youtube.com/watch?v=Zyhm40tj7bU> i've implemented the 
following:

   - There is a shortcut to displaying the object indexes on the screen. Then 
there is a "goto" dialog where you type the index of the object and it selects 
it for you.

(DesireData could display the indexes too).

Not only this is useful for this "goto" keyboard selection method (which 
allows navigating faster and to objects that are not in your connection path) 
but it can also make dynamic patching easier. Plus it might be useful for 
commands if we decide for a console. Like creating connections on the console 
you could use those indexes. Something like

conn 10-3 -> 23-1

to connect the 3rd outlet of object #10 to the 1st inlet of object #23


3. DesireData implemented a "object class list" and an suggestion windows. We 
already have that in the "completion-plugin" (it's on deken. btw a new release 
is planned for the near future). I've been using it literally everyday and it 
saves me A LOT of typing. People seem to like it a lot, i even got some inboxes 
on FB talking about it. Also we had testers that said it works normally on 
Raspberry Pi :)

4. It would be nice if 
connection.mpeg<http://artengine.ca/desiredata/gallery/connection.mpeg> showed 
the keystrokes. But looks impressive.


Cheers,
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Keyboard patching

[Henri Augusto Bisognini]

Hi PD list!

I have an idea for a "keyboard patching" feature for PD that allows you to 
navigate connections with the keyboard.

It also allows for neatly placing objects when connecting new ones to any 
outlet!

I've made a little working prototype showing the idea. Basically you use 
Ctrl+arrows to nagivate inlets, outlets and connections.

Instead of always using the first one, when you place a new object (and 
auto-patch is enabled) the new object is connected to the selected outlet and 
placed exactly in the same exact X coordinates.

What do you think?

https://www.youtube.com/watch?v=Zyhm40tj7bU

Cheers,
Henri.

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] why some structs are defined in m_obj.c? + what are vinlets and voutlets?

[Henri Augusto Bisognini]

Thanks a lot for the info Christof, IOhannes and Miller. Everything is starting 
to make sense :)

Is there any kind of document containing development guidelines or an 
explanation of the inner workings of PD?

The closest i could find is the ChangeLog.txt (which contained precious 
information that really helped me get started) in the "original source notes" 
section .
<https://github.com/pure-data/pure-data/blob/master/src/CHANGELOG.txt#L135>

Cheers,
Henri.


De: Christof Ressi 
Enviado: terça-feira, 20 de novembro de 2018 15:29
Para: Henri Augusto Bisognini
Cc: pd-dev@lists.iem.at
Assunto: Aw: [PD-dev] why some structs are defined in m_obj.c? + what are 
vinlets and voutlets?

Hi,

you can actually use obj_starttraverseoutlet() to traverse the outlets like 
this:

// x is your object
t_outlet *outlet;
int nout = obj_noutlets(x);
for (int i = 0; i < nout; ++i){
obj_starttraverseoutlet(x, , i);
// do something with outlet
}

obj_starttraverseoutlet returns the connections from this outlet to other 
ojects (which you can traverse with obj_nexttraverseoutlet), but it also gives 
you the outlet via the second parameter (a t_outlet** so it can change your 
t_outlet* to point to the right outlet).

note that those functions are not part of the public API, so use with caution.

Christof


Gesendet: Dienstag, 20. November 2018 um 17:37 Uhr
Von: "Henri Augusto Bisognini" 
An: "pd-dev@lists.iem.at" 
Betreff: [PD-dev] why some structs are defined in m_obj.c? + what are vinlets 
and voutlets?

Hi.

I'm starting to dwelve into pd's C side of things. I'm having a really hard 
time figuring stuff out. (i have mainly experience with more high-level 
languages like Java, etc)

I'm trying to experiment with some editor features and i've been wandering:

why the _inlet and _outlet structures are defined in m_obj.c instead of m_pd.h ?

This way i can't access the structure members. I'm trying to traverse an 
t_object's t_outlets linked list but

t_outlet *o = selected_object->te_outlet;
o = o->o_next;
but this throws me an "dereferencing incomplete type" error since there is no 
definition for t_outlet inside m_pd.

 The same goes for accessing members of t_outconnect for example, but there are 
two methods that allows you to traverse the connections linked list
obj_starttraverseoutlet()   (m_imp.h)(m_obj.c)
obj_nexttraverseoutlet()   (m_imp.h)(m_obj.c)


But i couldn't find any method to traverse an t_object's linked list of 
t_outlets. The only three methods that seems to return t_outlets pointers are

t_outlet *outlet_new(t_object *owner, t_symbol *s)  
 (m_obj.c)
t_outlet *canvas_addoutlet(t_canvas *x, t_pd *who, t_symbol *s)  
(g_graph.c)
and
t_outlet *voutlet_getit(t_pd *x)(g_io.c)
which i currently do not understand but doesn't seem to be what i'm looking for.

How could i traverse from, lets say the g_editor.c file, all the t_inlets and 
t_outlets of an t_object?

Btw, on a second question, what exactly are vinlets and voutlets?

Cheers,
Henri.___ Pd-dev mailing list 
Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] why some structs are defined in m_obj.c? + what are vinlets and voutlets?

[Henri Augusto Bisognini]

Hi.

I'm starting to dwelve into pd's C side of things. I'm having a really hard 
time figuring stuff out. (i have mainly experience with more high-level 
languages like Java, etc)

I'm trying to experiment with some editor features and i've been wandering:

why the _inlet and _outlet structures are defined in m_obj.c instead of m_pd.h ?

This way i can't access the structure members. I'm trying to traverse an 
t_object's t_outlets linked list but

t_outlet *o = selected_object->te_outlet;
o = o->o_next;
but this throws me an "dereferencing incomplete type" error since there is no 
definition for t_outlet inside m_pd.

 The same goes for accessing members of t_outconnect for example, but there are 
two methods that allows you to traverse the connections linked list
obj_starttraverseoutlet()   (m_imp.h)(m_obj.c)
obj_nexttraverseoutlet()   (m_imp.h)(m_obj.c)
But i couldn't find any method to traverse an t_object's linked list of 
t_outlets. The only three methods that seems to return t_outlets pointers are

t_outlet *outlet_new(t_object *owner, t_symbol *s)  
 (m_obj.c)
t_outlet *canvas_addoutlet(t_canvas *x, t_pd *who, t_symbol *s)  
(g_graph.c)
and
t_outlet *voutlet_getit(t_pd *x)(g_io.c)
which i currently do not understand but doesn't seem to be what i'm looking for.

How could i traverse from, lets say the g_editor.c file, all the t_inlets and 
t_outlets of an t_object?

Btw, on a second question, what exactly are vinlets and voutlets?

Cheers,
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Intelligent Patching Feedback

[Henri Augusto Bisognini]

Hi!

I'm going to writing some ideas on intelligent patching, just to bring some 
discussion


  1.  It IS a dream come true!
  2.  Prior to pd 0.49 if you have some objects selected and then select a 
connection, the objects are automatically deselected. Now if you have objects 
selected and you click a connection the connection is added to the selection. 
In PD (and usually in general) when you want to add to a selection you need to 
hold shift. Maybe it's a good idea to have to shift+click a connection to add 
it to the selection.
 Right now i keep accidentally deleting objects because i'm used to the 
shift+select stuff in programs so i forget now a simple click in a connection 
will keep what was already selected. But nothing to worry about 
because now i can just ctrl+z my way back! :)
  3.  An enchancement idea for the fan out. Currently the fan out (when you 
select multiple destination objects and connect a single object to one of them) 
the connections are made according to the creation order of the objects (that 
becomes evident when you triggerize). Maybe PD could do it in right-to-left 
order.
  4.  While he have a fan-in from multiple-to-one i imagine a one-to-one fan in 
also being handy :)
(example: connect all the outlets of a [route A B C D E F G] to a 
[list]'s inlet. )
  5.  When using the "triggerize" the [t] objects appears with some offset to 
the left of the object being "triggerized".
 For what i've seen in the code the [t] object is created by reading 
obj->te_xpix; and obj->te_ypix;
 Maybe this is an issue with positions reported by the windows manager?
 I've measured and the [t] object is created 10 pixels to the left. The 
window border is just 7 pixels but Win7 does apply some shadows around the 
window
 that might account for that 3 pixels difference. But it's just an 
guess.

Cheers
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

[PD-dev] Two preferences menus

[Henri Augusto Bisognini]

I've noticed there are two equal preferences menus on Windows and Ubuntu.

File->Preferences
Edit->Preferences

Is it intentional or some leftover after a change?

Cheers
Henri.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] roadmap for Pd-0.49?

[Henri Augusto Bisognini]

Hi! Since we got on the subject of 0.49 do you guys mind if i ask a couple 
questions about what's planned? Just out of curiosity and excitement : )

-I see there's a PR (#383) that adds a delete method for [pointer]. There's any 
forecast for that feature? I've been waiting that one heh

-Also will 0.49 come with the intelligent patching features IOhannes been 
working on? That will be a dream come true.

Cheers
Henri.



De: Pd-dev  em nome de Miller Puckette 

Enviado: sábado, 1 de setembro de 2018 21:28
Para: Christof Ressi
Cc: pd-dev
Assunto: Re: [PD-dev] roadmap for Pd-0.49?

Looking back I've only been able to get out a bit fewer than one major
release per year... I hope to speed this up now that there are much better
scripts and tools in place (thanks mostly to other people!)

My own situation is that I go into heavy teaching mode again Sept. 24 so
I'll either succeed and get out 0.49 before then or fail and only get it out
late December.  If I do get 0.49 working quickly I'll then aim for 0.50 in
February or March.

For 0.49 I want to fix the escaping of '\' characters (I had earlier tried
to make it possible simply never to make a `\` character visible to the
user but this has turned out to be impossible).  Also I want to fix pasting
to place objects under the mouse (or at the very least, somewhere visible,
not off the edge of the window)

For the medium term I'm thinking about revisiting array drawing to make it
more efficient and controllable, and expanding the capabilities of the 'atom'
box (lists; texts).

Also I have a vague plan to make an API feature to guide DSP graph sorting
order, e.g., to request that one item in a patch be sorted in advance of
another without them being connected by a patch cord.

Anyway, I think whatever happens to 0.49 I can deal with feature PRs anytime
this fall and get them into a release by late winter.

cheers
Miller

On Sun, Sep 02, 2018 at 12:32:47AM +0200, Christof Ressi wrote:
> Hi Miller,
>
> I just wanted to ask what's your approximate roadmap for Pd 0.49? Do I need 
> to hurry up if I want to propose stuff or is there plenty of time left? :-)
>
> Christof

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PD AutoComplete Plugin

[Henri Augusto Bisognini]

On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote:

>äh?
> you really don't want to autocomplete *that*.

I don't even know what that does, i was just looking for stuff with long names 
haha



On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote:
> these examples puzzle me a bit, as they are quite the reverse of what i  
> consider "monolithic libraries".
> when loading zexy as a multi-object library (aka "monolithic library"),
> then there will be *no* [zexy/demultiplex] object, just [demultiplex].

On 06/11/2018 07:11 PM, Henri Augusto Bisognini wrote:
> You can find them separately using a special "monolithic search mode" that 
> displays the library name on the completions list but only auto completes the 
> object name (since you can't use namespaces with those).

That's why the auto complete shows the library name in the suggestion windows 
but doesn't type it.

For example, you will search for ",demu" ant it will display "zexy/demux" so 
you know you should load zexy, but when you press enter it will only type demux 
:)


The gif on the readme.md in the repository shows the three search modes in 
action.






On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote:

> not sure whether this is directed at me (i don't remember saying anything 
> about performance)


Oh, sorry, i forgot to Ctrl+V the text quoting Dan. It should be


On 06/10/2018 15:58 PM, Dan Wilcox wrote:

> The other aspect is more organizational: how/when do we integrate new things 
> into the pd "core" and keep it maintainable. There is a conscious decision 
> not to put *everything* into to core but some things may > make sense. 
> However I'd suggest *lots* of testing and built-in extensibility before 
> making a formal proposal for it to be adopted. For instance, does this plugin 
> impact GUI performance when patching on slow > machines ie. RPI? I don't 
> know, but it would be good to find out before adding something that would 
> then be *expected* to work well.

"About it running on slow computers like Raspberry Pis. What exactly would be 
the the problem? Processing or memory?"


I read on the Netiquette that "Never ever reply to a digested email if you do 
not refer to exactly one email in the digest."

Does that apply to standard emails too? Sorry if that's the case. This mailing 
list thing is completely new to me.


Cheers,
Henri.



De: Pd-dev  em nome de IOhannes m zmölnig 

Enviado: segunda-feira, 11 de junho de 2018 15:47
Para: pd-dev@lists.iem.at
Assunto: Re: [PD-dev] PD AutoComplete Plugin

On 06/11/2018 07:11 PM, Henri Augusto Bisognini wrote:
> zexy/0x3d0x3d0x7e

äh?
you really don't want to autocomplete *that*.

> The only thing it can't do is to read inside those sys dependent files to 
> know what objects are there inside monolithic libraries, like zexy. For that 
> reason it reads a .txt file that the user can set that contains that 
> information. Something like:
>
> [...]
> zexy/atoi
> zexy/demultiplex
> zexy/demux
>

these examples puzzle me a bit, as they are quite the reverse of what i
consider "monolithic libraries".
when loading zexy as a multi-object library (aka "monolithic library"),
then there will be *no* [zexy/demultiplex] object, just [demultiplex].

so: are we really talking about the same thing here?
> It would definitely be better to communicate with pd directly to query those 
> objects. Is that possible for a GUI plugin?

not for a gui-plugin alone.
however, you can write "mixed-mode plugins" that consist of a both a
gui-plugin and an external (https://git.iem.at/pd-gui/punish/ uses this
quite a lot; it's basically a gui-plugin that tells Pd-core to load an
external to add the necessary C-parts).

> About it running on slow computers like Raspberry Pis. What exactly would be 
> the the problem? Processing or memory?

not sure whether this is directed at me (i don't remember saying
anything about performance)

> Right know the plugin only increases 424kb in RAM usage on my windows 
> computer and i have a reasonable amounts of externals.

however, i think that the number of autocompletable objects will only
have very little impact on the total RAM used by Pd(gui).
i wouldn't worry about the memory foot-print at all :-)


gfmdsar
IOhannes

___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PD AutoComplete Plugin

[Henri Augusto Bisognini]

Yes, definitely!

I didn't mean in merging right now. It's an idea for the future. That's why i'm 
starting this discussion now. To be prepared and take considerations regarding 
that goal during development and for devs to share their ideas on the subject.

Right know the plugin overwrites the pdtk_text_editing proc in pdtk_text.tcl 
and the script is only triggered when the user presses the Tab key. I'm not 
100% about limitations and implications of this. For ex:


- what if other plugin by any change also overwrites pdtk_text_editing? 
(unlikely but possible)
- it would be nice that after writing "[send" the auto complete plugin allowed 
seraching among send/receive names. Such thing was intended by Yvan but in his 
implementation he could only detect when those names were created. But the user 
might just delete all [s][r] objects with those names, rename all of them or 
just close their containing patch. This way the names would still appear as 
suggestions despite not existing anymore. The names would also be lost between 
pd sessions. That's why right know i just disabled this feature. So i think i 
direct communication with pd would be the best way to do this. Would this be 
possible without integration with PD?

It's all on an early stage but just some updates on the current state of 
testing:

-We've been testing the plugin and it reportedly worked in all win 7 machines 
we've used.
-Worked in some linux machines but we found minor problems in others.
-(Sierra/Yosemite) The listbox popup doesn't show on OS X right know but the 
rest of the plugin is working (the user can press up/down and type enter to get 
a random object, which tells us the underlying code is working)


We need more tests in all platforms! Running PD in RPI is more advanced so i 
guess it will be easier to find people to test it in the mailing lists :)

Cheers,

Henri.


De: Dan Wilcox 
Enviado: domingo, 10 de junho de 2018 15:58
Para: Henri Augusto Bisognini; Alexandre Torres Porres
Cc: pd-dev
Assunto: Re: [PD-dev] PD AutoComplete Plugin

Technically, you can distribute GPL parts as long as they can be freely 
upgraded/replaced by the user. Since the part in question is a plugin script 
and not compiled into the Pd binary, it's my understanding that it doesn't 
infringe upon the library aspect of the GPL and the Pd source is already open.

The other aspect is more organizational: how/when do we integrate new things 
into the pd "core" and keep it maintainable. There is a conscious decision not 
to put *everything* into to core but some things may make sense. However I'd 
suggest *lots* of testing and built-in extensibility before making a formal 
proposal for it to be adopted. For instance, does this plugin impact GUI 
performance when patching on slow machines ie. RPI? I don't know, but it would 
be good to find out before adding something that would then be *expected* to 
work well.

On Jun 10, 2018, at 12:00 PM, 
pd-dev-requ...@lists.iem.at<mailto:pd-dev-requ...@lists.iem.at> wrote:

From: Alexandre Torres Porres mailto:por...@gmail.com>>
To: Henri Augusto Bisognini 
mailto:msndohe...@hotmail.com>>
Cc: "pd-dev@lists.iem.at<mailto:pd-dev@lists.iem.at>" 
mailto:pd-dev@lists.iem.at>>
Subject: Re: [PD-dev] PD AutoComplete Plugin
Message-ID:
mailto:caeasfmh28zegiyng92e8sc6xuffnzlbwolgxeste4isrtt2...@mail.gmail.com>>
Content-Type: text/plain; charset="utf-8"

OMG, this HAS to be part of the vanilla distribution!

I'll definitely test it and check it out.

I don't know much about licenses, there wouldn't be a problem to include a
GPL tcl code into Vanilla, right? Or would it help if it were BSD?

cheers


Dan Wilcox
@danomatika<http://twitter.com/danomatika>
danomatika.com<http://danomatika.com>
robotcowboy.com<http://robotcowboy.com>



___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] PD AutoComplete Plugin

[Henri Augusto Bisognini]

I've emailed Yvan about that and he's willing to change the code's license. But 
we're not sure how it should proceed.

Just to make sure: he would have to create another minor version (0.43 in that 
case) to be able to change from GPL to BSD or LGPL, right? Or can he just 
change the license right away?


De: Alexandre Torres Porres 
Enviado: sábado, 9 de junho de 2018 22:07
Para: Henri Augusto Bisognini
Cc: pd-dev@lists.iem.at
Assunto: Re: [PD-dev] PD AutoComplete Plugin

OMG, this HAS to be part of the vanilla distribution!

I'll definitely test it and check it out.

I don't know much about licenses, there wouldn't be a problem to include a GPL 
tcl code into Vanilla, right? Or would it help if it were BSD?

cheers
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev