Re: [PD-dev] multi-architecture deken packages

[Martin Peach]

Given that deken already lets you ship the source along with the
binaries, it seems better (to me at least) if deken could also build
them on the actual machine that will be running them. At least for the
linux Pis and Beaglebones, which almost always have the toolchains
installed by default.
So you could provide a basic binary that will run on any arm cpu, but
also the possibility to build an optimized version.

Martin

On Thu, Apr 15, 2021 at 12:27 PM Alexandre Torres Porres
 wrote:
>
> Thanks for all the clarifications, it's still hard for me to follow it all, 
> but I think I got the most of it :)
>
> Bottom line, we gotta test a RPi with binaries for armv6 and armv7,  if no 
> significant improvement is found on armv7 (and there might not be), let's 
> just ship armv6.
>
> The only issue is that deken might not give the armv6 option for armv7. But 
> the funny part is that most people with a RPi 3 and stuff end up getting 
> armv6 instead anyway :) not sure what to do about that. Hopefully this 
> information for RPi users can be easily found.
>
> Anyway, me and Esteban will do the tests for armv6 vs armv7 in his RPi 3!
>
> Cheers
>
>
> Em qui., 15 de abr. de 2021 às 08:25, IOhannes m zmölnig  
> escreveu:
>>
>> On 4/14/21 23:59, Alexandre Torres Porres wrote:
>> > Em qua., 14 de abr. de 2021 às 18:29, IOhannes m zmölnig 
>> > escreveu:
>> >
>> >>> But one can also just ship armv6 and aarch64 and it should work for
>> >>> everybody, right?
>> >>
>> >> as said before: somebody should do some benchmarking how much gain there
>> >> is for armv7 with respect to armv8.
>> >>
>> >
>> > I don't understand because I was talking about *armv6* (Linux-armv6-32) and
>> > *aarch64* (Linux-arm64-32).
>>
>> the "as said before" was referring to some other mails years ago.
>> iirc, something that triggered
>>https://lists.puredata.info/pipermail/pd-list/2019-06/125453.html
>>
>> >
>> > You said it yourself that we should use *armv8* for the 32 bit variant
>> > (Linux-armv8-32), and *aarch64* for this other one. We're also agreeing
>> > *armv8*/Linux-armv8-32 is pointless. So I guess you mean armv8
>> > as (Linux-arm64-32) and *aarch64*.
>>
>> no. i'm pretty sure i meant 32bit arm architectures.
>> i think the main concern is the speed-boost between armv6 vs armv7.
>> the latter has (usually) better support for (single precision) floating
>> point math, and might give a significant speed gain when doing signal
>> processing.
>>
>> otoh, it might not be able to fully utilize the additional instruction
>> set if there's no explicit code for it (as would be typical for
>> pd-extenrals)
>> (see also http://single-boards.com/armv6-vs-armv7/)
>>
>> that's why i keep mentioning benchmarks.
>>
>> the armv7 vs armv8 (aarch32!) debate is basically the same, though i
>> guess(!) speed improvements might not be as prominent.
>>
>>
>> >
>> > Now, my understanding is that *aarch64* can't run anything else other than
>> > this... can it run *armv6* and *armv7*?
>>
>> can you run intel/32bit externals on your intel/64bit mac book? yes
>> can you run intel/32bit externals within your Pd-intel/64bit on that
>> same mac book? no
>>
>> fgmsard
>> 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



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

Re: [PD-dev] Macs to transition to ARM processors

[Martin Peach]

On Tue, Jun 23, 2020 at 5:21 AM Christof Ressi  wrote:
>
> > but knowing Apple they might well change the file format anyhow just to 
> > force some more upgrades
> Yes, from what I understood from the articles I've read, they want to
> create a new file format for fat x86_64 / arm binaries.
>
> What I don't understand is: the FAT format already supports all kinds of
> binaries, including ARM64 (CPU_TYPE_ARM64). Also, I don't see why apple
> shouldn't be able to keep supporting existing x86_64 binaries (FAT or
> mach-O) on their ARM machines...
>
> But I'm sure they have technically convincing reasons for this :-p. But
> let's see.

It's known as 'planned obsolescence'. It allows a monopoly to charge
'technological rent' above and beyond any added value from the
manufacturing princess.

Martin



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

Re: [PD-dev] 64-bit vs 32-bit info

[Martin Peach]

On Thu, May 28, 2020 at 2:53 PM IOhannes m zmölnig  wrote:

> the more complicated part is the first one, as it requires to actually
> open the file that dlopen()/LoadLibrary() could not open and inspect the
> binary data to understand the architecture of the blob.

Perhaps getLastError() or errno would give a clue after the calls to
dlopen()/LoadLibrary() fail, without needing to inspect the file.
Usually there are  a few different errors possible.

Martin



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

Re: [PD-dev] compiler oopses compiling s_net.c on windoze

[Martin Peach]

On Thu, May 28, 2020 at 11:36 AM Miller Puckette via Pd-dev
 wrote:
>
> This will sound precious, but I have a policy of pushing back against the
> forced-upgrade pratcices of Microsoft and Apple.  I suspect many people 
> outside
> of Europe/North America are using very old machines.
>
> At any rate, I now plan to put out a 64-bit test version compiled with IPV6
>  support (-DWINVER=0x0600 -D_WIN32_WINNT=0x0600 as Iohannes suggests), and 
> later
> go back and provide XP versions in 64 and 32 bits.
>

Is there any way for a user to know if their version of Pd is 32 or 64
bit while it's running? Attempting to load externals of the wrong type
just gives those vague 'unable to load' errors. If the 'About PD'
window would say which address size it uses that could help. (I use
different versions on a few different machines and I can't remember
which is which)
Help->About Pd gives: "Pd version 0.50.0", maybe it could say "Pd
version 0.50.0 (64-bit addressing)".


Martin



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

Re: [PD-dev] Bit fields in t_editor

[Martin Peach]

On Thu, Feb 13, 2020 at 9:24 PM Henri Augusto Bisognini
 wrote:
>
> 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?

They are all unsigned ints with some of their bits used, so they are
aligned already to whatever bit-size ints are.

Martin



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

Re: [PD-dev] Converting arbitrary strings to symbol in an external

[Martin Peach]

I take it to mean that there is an actual string at the location pointed to
by s.
To convert a float to a string, first sprintf(s, "%.0f", a_float);
or sprintf(s, "foo-%d", (int)a_float);
(ensure you have space at s for the string).
Then convert the string to a symbol with gensym.

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

Re: [PD-dev] pdlibbuilder and static linking pthread by default on Windows.

[Martin Peach]

On Wed, Feb 7, 2018 at 11:50 AM, Lucas Cordiviola 
wrote:

> There were many problems back in 2016 with people that didn't have
> pd-extended installed. For them when downloading from deken many objects
> didn't work. One of the causes was that those "extended" .dlls where using
> pthread-GC-2.dll. This file was installed by pd-extended installer on
> windows system folders.
>
> Attached is a list of missing dlls on 2016.
>
> Now we have included those dlls in each pkg so [externals] work without
> having pd-extended installed.
>
> The actual libwinpthread-1.dll could change in future MinGWs so externals
> compiled today may stop working.
>
Is it possible to just use one pthread dll for all the externals, the one
that comes with Pd? They should all have the same functions in them, so it
would just be a matter of changing the linker LIBS.
In externals/Makefile pthreadGC2 occurs just once at the beginning, this is
the one used in mrpeach.
I attach a list of all the lpthreads mentioned in all the files in the
externals directory (at
https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/).
Most of them are pthread for linux or MacOS (except
iem/iemnet/Makefile:41:LIBS_windows=-lpthread), 18 are pthreadGC and four
are pthreadVC. It's possible some of the pthreads are for Windows as well.

Martin
./august/readanysf~/Makefile:23:PD_LDFLAGS =  -L$(GAVLPREFIX)/lib  -lgavl 
-lgmerlin_avdec -lpthread 
./august/readanysf~/Makefile.win:18:LDFLAGS += -lpd -lwsock32 -lkernel32 
-luser32 -lgdi32 -lpthreadGC2 $(GMERLIN_LIBS)
./bbogart/gphoto/makefile:15:-lgphoto2 -lpthread
./build/win/netclient.libs:1:-lwsock32 -lpthreadGC2
./build/win/netdist.libs:1:-lwsock32 -lpthreadGC2
./build/win/netrec.libs:1:-lwsock32 -lpthreadGC2
./build/win/netserver.libs:1:-lwsock32 -lpthreadGC2
./build/win/oggamp~.libs:1:-lwsock32 -lpthreadGC2
./build/win/oggcast~.libs:1:-lwsock32 -lpthreadGC2
./grill/flext/.svn/pristine/f4/f4ac9b6f8222176fb47eddede95bb10bc17ad6f6.svn-base:15:LIBS
 += -lpthreadVC2
./grill/flext/.svn/pristine/f4/f4ac9b6f8222176fb47eddede95bb10bc17ad6f6.svn-base:17:LIBS
 += -lpthreadVC
./grill/flext/buildsys/win/pd/gnumake-mingw.inc:15:LIBS +=  -lpthreadVC2
./grill/flext/buildsys/win/pd/gnumake-mingw.inc:17:LIBS +=  -lpthreadVC
./hardware/itrax2/makefile:14:LIB = -ldl -lm -lpthread
./iem/hdspm_mixer/makefile:8:LIB = -ldl -lm -lpthread
./iem/iemgui/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iemgui/src/makefile_linux:9:LIB = -ldl -lm -lpthread
./iem/iemnet/.svn/pristine/94/94c749b33a349a8a3c122eb8ec15a0d08d514b86.svn-base:41:LIBS_windows=-lpthread
./iem/iemnet/Makefile:41:LIBS_windows=-lpthread
./iem/iem_adaptfilt/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_adaptfilt/src/makefile_lin:8:LIB = -ldl -lm -lpthread
./iem/iem_ambi/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_atan2/src/makefile:8:LIB = -ldl -lm -lpthread
./iem/iem_atan2/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_atan2/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_bin_ambi/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_bin_ambi/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_delay/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_dp/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_dp/src/makefile_linux:9:LIB = -ldl -lm -lpthread
./iem/iem_matrix/src/makefile:8:LIB = -ldl -lm -lpthread
./iem/iem_matrix/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_matrix/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_roomsim/src/makefile:8:LIB = -ldl -lm -lpthread
./iem/iem_roomsim/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_roomsim/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_spec2/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/iem_spec2/src/makefile_linux:8:LIB = -ldl -lm -lpthread
./iem/iem_tab/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iem/pdoctave/Makefile:8:LIB = -ldl -lm -lpthread
./iemlib/iemlib1/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iemlib/iemlib2/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iemlib/iem_mp3/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./iemlib/iem_t3_lib/src/makefile_darwin:9:LIB = -ldl -lm -lpthread
./input_noticer/Makefile:19:LINUXLDFLAGS = `pkg-config --libs glib-2.0 hal 
dbus-glib-1` -lpthread -lgthread-2.0 -lglib-2.0
./Makefile:79:-lwsock32 -liphlpapi -lpthreadGC2 -lkernel32 -luser32 -lgdi32 
-lregex -liberty
./maxlib/Makefile:41:LIBS_windows = -lpthread
./moocow/common/m4/ax_pd_external.m4:355:  LIBS="$LIBS -lpd -lwsock32 
-lpthreadGC2 -lkernel32 -luser32 -lgdi32 -lregex"
./moocow/deque/configure:3861:  LIBS="$LIBS -lpd -lwsock32 -lpthreadGC2 
-lkernel32 -luser32 -lgdi32 -lregex"
./moocow/flite/configure:4401:  LIBS="$LIBS -lpd -lwsock32 -lpthreadGC2 
-lkernel32 -luser32 -lgdi32 -lregex"
./moocow/gfsm/configure:20523:  LIBS="$LIBS -lpd -lwsock32 -lpthreadGC2 
-lkernel32 -luser32 -lgdi32 -lregex"
./moocow/locale/configure:3861:  LIBS="$LIBS 

Re: [PD-dev] pdlibbuilder and static linking pthread by default on Windows.

[Martin Peach]

To return to the original subject of this thread, if I install Pd for
Windows from Miller's site I get libwinpthread-1.dll and pthreadVC.dll in
Pd/bin. So I don't see why it's necessary to ship either or both along with
an external, or to statically link them. It seems to needlessly duplicate
code and possibly introduce version conflicts.

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

Re: [PD-dev] pdlibbuilder and static linking pthread by default on Windows.

[Martin Peach]

On Tue, Feb 6, 2018 at 10:43 AM, IOhannes m zmoelnig 
wrote:

>
> in Pd-extended, there are 10 out of 112 (different) libraries usable on
> Windows in the entire deken repositories that have the libpthread
> library included, presumably because they actually need this library.
>
> of these 10 libraries, the following 6 come from the big Pd-extended
> import, and have not been updated since (and are presumably unmaintained):
> - hidin
> - iemxmlrpc
> - mrpeach (+ net)
> - pdogg
> - unauthorized
>
> I have been workjng on mrpeach in sourceforge svn recently, so I _am_
maintaining it, although pthreads was probably imported from somewhere
else. AFAIK it's only needed for some of the net objects like [tcpserver].
I am really not sure how to build an external on a Windows system. All the
docs in pdinfo are several years old.
The readme here:
https://github.com/pure-data/pure-data/tree/master/msw
talks about some hybrid build system on wine using mingw and msw but gives
no indication of how to set it up.
I don't see why one must use a linux box to compile for Windows, it's just
offputting. On Windows, I usually give up trying after a day or so of
filling my drive with mingw and cygwin and getting nowhere.
I also try to build using Visual Studio, but there again the versions are
usually incompatible with whatever pd.lib was built with.
As I've mentioned before, the c runtime libraries that mingw and msw link
against are not compatible, and possibly neither are the pthread dlls.
It would be nice if the 'official' tool chain for building externals that
work with vanilla Pd on a Windows machine in 2018 could be explicitly
documented somewhere.

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

Re: [PD-dev] [pure-data:svn] New commit [r17643] by mrpeach

[Martin Peach]

On Thu, Oct 12, 2017 at 3:24 PM, IOhannes m zmölnig <zmoel...@iem.at> wrote:

> On 10/12/2017 08:03 PM, Martin Peach wrote:
> > Since yesterday I've been trying to build midifile.c for Windows7 using
> > Visual Studio 2017. When I run the resulting dll using midifile-help.pd
> it
> > crashes Pd (0.48.0 installed from Miller's site) whenever sys_fopen() is
> > called. Doing the same thing using fopen() from stdio.h works fine.
>
> you mean, that sys_fopen() is crashing and never returning (rather than
> using the FILE returned by it)?cd
> can you open other files with Pd?
> e.g. can you *save* a Pd file?
>
>
Yes, when my midifile dll calls sys_fopen in the running instance of Pd, Pd
disappears from the screen. I was getting a crash report dialog, but not
any more. The Pd program runs fine, I can open and save patches. Also the
version of [midifile] from deken works fine, but I don't know how that was
built.
___
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] [pure-data:svn] New commit [r17643] by mrpeach

[Martin Peach]

On Thu, Oct 12, 2017 at 4:38 AM, IOhannes m zmoelnig 
wrote:

> On 2017-10-11 23:00, Pure Data Computer Music System SVN repository wrote:
> > Don't use sys_fopen with MSVC as its FILE struct is not compatible.
>
> hmm, i'm pretty sure this is the wrong approach.
> the sole purpose of sys_fopen() is to help Windows users (as it wraps
> the use of non-ascii filenames!). on non-windows platforms sys_fopen()
> is basically identical to fopen().
>
> i guess the problem you are having is hat the FILE handle returned by
> _fopen() depends on the libC implementation, and if Pd has been linked
> against a different libc implementation than midifile, they might be
> "incompatible".
>

Precisely. I have been bitten by that before.

e.g. this is the reason why Pd provides a sys_fclose() (since running
> flose() on a sys_fopen()ed file would leak ressources).
>
> since there's a number of externals that are successfully using
> sys_fopen()/sys_fclose(), wonder what goes wrong in midifile.
> what exactly is meant by "incompatibility"?
>
>
It's only sys_fclose() (and things that use FILE) that doesn't work,
calling Pd functions like post() cause no trouble.

since when does the problem exist? (e.g. did something change in the Pd
> build process that triggered that error?)
>
>
Since yesterday I've been trying to build midifile.c for Windows7 using
Visual Studio 2017. When I run the resulting dll using midifile-help.pd it
crashes Pd (0.48.0 installed from Miller's site) whenever sys_fopen() is
called. Doing the same thing using fopen() from stdio.h works fine.

The makefile in Miller's distribution has
VCSDK = "C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A"
VC9 = "C:\\Program Files\\Microsoft Visual Studio 9.0\\VC"
MSCC = cl
MSLN = link

I'm using a different version of the same MS tools and building from the
IDE. Possibly the c runtime is not the same? I would have expected a
conflict if using MinGW.

Here is some info relevant to the situation, bur I'm not sure what to do
with it:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries


is there some bug-report against Pd about sys_fclose() being unusable on
> W32?
>
>
> fgasmr
> 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] comport - compilation with mingw

[Martin Peach]

On Mon, Feb 27, 2017 at 4:28 AM, Roman Haefeli  wrote:

> ...
>
> I see you fixed even more for Windows than what I did. I would like to
> integrate your changes, but there are some questions left. The svn log
> suggests that you applied some changes specifically for Windows 10. In
> the diff, I see you wrapped some lines of code in:
>
> #ifdef _MSC_VER
>
> If I understand correctly, those lines are only used when compiling
> with Microsoft Visual Studio and mingw wouldn't use those lines. I'm
> compiling with mingw and would like the result to work will in Windows
> 10, too. Now, my question is: Should the code you put in between
> '#ifdef _MSC_VER' always be used when targeting Windows, regardless of
> the compiler or is that code really specific for MSVC?
>
>
It's used to specify the use of sprintf_s() and  strncpy_s(), the safer
versions of sprintf() and strncpy(). If your compiler knows about these
functions it would be better to use them, but not essential.

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

Re: [PD-dev] comport - compilation with mingw

[Martin Peach]

On Sun, Feb 26, 2017 at 3:10 PM, Roman Haefeli  wrote:

> Hey all
>
> I'm trying to cross-compile comport for Windows on Linux and stumbled
> across this error:
>
> i686-w64-mingw32-gcc -DPD -I "/home/roman/.wine/drive_c/Pd//src/" -DMSW
> -DNT -o comport.o -c comport.c
> comport.c: In function ‘set_break’:
> comport.c:422:29: error: ‘nr’ undeclared (first use in this function)
>  if (status != 0) return nr;
>
> Interestingly, only the compiler that targets Windows complains about
> it. comport compiles fine for all Linux platforms I tried.
>
> Without really understanding what the purpose of the parent function
> 'set_break' is, I went ahead and "fixed" line 422 to:
>
>  if (status != 0) return on;
>
> I can now compile comport for Windows (and still for Linux) and the
> resulting binary loads fine, but I'm not able to judge whether this is a
> sensible fix. I simply tried to address what error message gave me without
> really knowing what I'm doing.
>
> Can someone confirm that it was broken before this is the right way to
> address it?
>
> I got comport from:
> http://git.puredata.info/cgit/svn2git/libraries/comport.git/
>
>
That sounds familiar. I thought I already fixed that in sourceforge svn,
maybe it didn't get copied to git or I forgot to actually commit?

I was working here:
https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/iem/comport/
Is this obsolete now?


> Thanks,
> Roman
>
> ___
> 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] pdlua: lua-5.3 problem with float/int representation

[Martin Peach]

On Mon, Aug 1, 2016 at 11:59 AM, Patric Schmitz 
wrote:

> Hi pd devs,
>
> I'm using pd 0.47.1 on archlinux which ships the latest lua-5.3
> by default. It seems that in 5.3 the internal representation of
> 'number' types differentiates between floating and integer types
> now. Quoting the manual:
> > The type number uses two internal representations, or two subtypes, one
> called integer and the other called float. Lua has explicit rules about
> when each representation is used, but it also converts between them
> automatically as needed (see §3.4.3).
>
> and also from §3.4.3:
"The conversion from numbers to strings uses a non-specified human-readable
format. For complete control over how numbers are converted to strings, use
the format function from the string library (see string.format
). "

In pd.lua,
function pd.Class:dispatch(inlet, sel, atoms)
  local m = self["in_" .. inlet .. "_" .. sel]
and
  m = self["in_" .. inlet]
...here we are looking for a function in the .pdlua script by building a
string
using the inlet number, which is a lua_Number and will be printed however
lua decides to print it.


This led to the problem that the 'inlet' variable to string
> conversion resulted in the value 1.0 instead of 1, so the
> dispatching of the method failed since no method named e.g.
> in_1.0_float exists.
>
> I was able to fix it by making the inlet value integral with
> > inlet = math.floor(inlet)
> in pd.lua pd.Class:dispatch.
> \
>
inlet = string.format("%d", inlet)
should also work.


> An integer-cast could be used as well, but that would not be
> compatible with older language versions. As found by Claude on
> IRC the floor version should be safe since "Rounding functions
> (math.ceil, math.floor, and math.modf) return an integer when the
> result fits in the range of an integer, or a float otherwise.".
> So as long as < 2^31 inlets are used, which one can reasonably
> assume, this should be fine.
>
> There are probably more places where this fix would need to be
> applied, such as the outlet dispatching, and the multi-receive
> example. It should also be commented to make obvious what is
> happening, like that no int-cast is used due to older language
> version compatibility.
>
> I think only two lines in pd.lua are affected by this. They could be
changed to
  local m = self["in_" .. string.format("%d", inlet) .. "_" .. sel]
and
  m = self["in_" .. string.format("%d", inlet)]
or
 local m = self["in_" .. math.floor(inlet) .. "_" .. sel]
and
  m = self["in_" .. math.floor(inlet)]

All the pd_lua scripts will usually pass through Class:dispatch so if the
correct function names are generated therein, there will be no other
effects.
pd_lua scripts may use integers internally of course but Pd itself uses
only floats. (And lua numbers are either doubles or floats,  pdlua.c will
convert them to float.)

Thanks for pointing this out,

Martin



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

Re: [PD-dev] overview of upstream sources?

[Martin Peach]

According to the FAQ at gnu .org
(http://www.gnu.org/licenses/gpl-faq.html#UnchangedJustBinary):
I downloaded just the binary from the net. If I distribute copies, do I
have to get the source and distribute that too?

Yes. The general rule is, if you distribute binaries, you must distribute
the complete corresponding source code too. The exception for the case
where you received a written offer for source code is quite limited.

...doesn't this imply that deken should also provide the source code
itself, at least as an option?

Martin

On Tue, Dec 22, 2015 at 8:07 AM, Roman Haefeli  wrote:

> On Thu, 2015-12-17 at 19:20 +0100, Fred Jan Kraan wrote:
>
> > >
> > > I would rather propose adding some mandatory meta information to deken
> > > uploads. A package that can be downloaded from puredata.info should at
> > > least contain the information which sources it was built from.
> >
> > The puredata.info could host such a list in the public wiki.
> >
> > It is not very convenient to download several packages just to find out
> > the most recent/bug free.
>
> Exactly. This is why there is a version field in deken packages.
>
> I don't see how something like a fork map helps the end user, i. e. the
> one using Pure Data and installing an external through deken. When you
> install something with deken, you primarily want to know what sources
> have been used to build that package. Once you know that, you might also
> want to know where those sources are forked from. Currently, you only
> know _who_ as uploaded a package, but you do not know _where_ the
> sources of a package are hosted.
>
> I'm not opposing the idea of a fork map, but there is more important
> information missing before that.
>
> Roman
>
> ___
> Pd-dev mailing list
> Pd-dev@lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
___
Pd-dev mailing list
Pd-dev@lists.iem.at
http://lists.puredata.info/listinfo/pd-dev

Re: [PD-dev] loading classes: search by directory rather than extension

[Martin Peach]

On Sun, Sep 27, 2015 at 3:30 PM, IOhannes m zmölnig  wrote:

> so i still believe that it is a good idea to have a place where the user
> can install libraries to without any special permissions, regardless
> where the Pd binary is installed.
>

It would also be a good idea if the non-power user could see, from within
Pd, a list of all the directories Pd will scan for externals and
abstractions. Then the user could choose which one to use. The Pd I have
here (Pd 0.46.6) has preferences->path which contains the single item
/usr/lib/pd/extra, which is not user-writeable. I can't find any reference
to the settings file. There is a 'save all settings' that may or may not
actually do something, but I'd need to be a power user to figure out which
file was changed.

As far as hidden directories they are (by design) hard to see...you have to
list your directories in a terminal with ls -al, usually not possible with
the double-click-on-an-icon approach which the non-power user tends to
adopt.

For example the Arduino IDE has a settings dialog that lets you change some
settings but also, in the same dialog, gives the path to the actual
settings file so you can change other settings with a text editor.

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

Re: [PD-dev] External development: preventing several copies of external

[Martin Peach]

On Sun, Jun 14, 2015 at 3:36 PM, Alexandre Clément 
alexandre.r.clem...@gmail.com wrote:

 Hello all!

 I'm creating an external which should only allow one copy loaded at the
 same time.
 Is there a way to check this upon creation?

 I tried going the same approach as checking if a receiver exists before
 attempting to send, but it doesn't seem to work.

 if (gensym(class_name)-s_thing) {
 post(Exists!);
 return false;
 }

 Because gensym generates the symbol if it wasn't already in the list.
What I do is have a global variable outside the class struct and check if
it is not zero before instantiating a new object.
Since c is guaranteed to initialize globals to zero, the first object
created can set it to some other value. Maybe some more trickery will be
needed if the object is deleted and recreated, possibly the code is still
in memory and the global will have the non-zero value; in this case the
free routine should zero the global,

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

Re: [PD-dev] HD support in Pd

[Martin Peach]

There is already a t_int in Pd, it just isn't used. I made a patch a few
years ago for a 'blob' type that's part of Pd-extended. You can look at
that to see how to implement it. Basically you add a default handler in Pd
for things that don't have a method for  t_int, that does nothing.

Martin

On Sun, Feb 22, 2015 at 9:52 AM, Jonathan Wilkes via Pd-dev 
pd-dev@lists.iem.at wrote:

 Hi Benoit,
 What do you mean by 64 bits version?  Do you that mean that you could
 get your protocol to work on Pd Double, the version of Pd that uses 64-bit
 floating point numbers?  If so that's probably the way to go-- and keep in
 mind that Pd Double can run on 32-bit architectures, so that isn't a
 problem.

 On the other hand if you want to code up a patch to a) add an int atom
 type, b) change Pd's parser to accommodate it, c) write a versioning
 mechanism so that the parser changes don't end up breaking old patches, and
 d) write a test suite, then I would certainly look at it.  I highly doubt
 it would make it into Pd Vanilla-- the increased UI complexity of the
 implicit typing probably overshadows the benefit of accommodating a new
 protocol that isn't vital to the normal functioning of the software.

 -Jonathan


   On Sunday, February 22, 2015 7:03 AM, BEB Digital Audio 
 beb.digitalau...@free.fr wrote:


 Hello everybody,

 I have just joined the Pd-dev list and I would like to introduce myself
 : I am one of the member of the MMA HD development group (amongst other
 things related to MIDI and RTP-MIDI developments ;-) )

 As you probably heard, the MMA has presented officially this new
 protocol during the NAMM2015 : http://www.midi.org/aboutus/news/hd.php
 This has been announced also on other places with some further details :

 http://www.synthtopia.com/content/2015/01/16/new-midi-hd-protocol-has-reached-a-milestone/

 So now, why am I here?
 The reason is simple : there is already a Max/MSP implementation of HD
 (still not public, because of the MMA NDA of HD, still active until HD
 is officially released in public domain), but no Pd...
 (By the way, it's not the only existing implementation of HD, believe me
 ;-) . Those who went to NAMM2015 could see a few other ones)

 I have taken a look to the possibility to include HD support in Pd
 (since I am the creator of the HD Max externals), but there is currently
 a huge stone in the middle of the road : HD is exclusively based on 32
 bits unsigned integer atoms... so it's simply impossile for now to
 encode HD messages in Pd because of the restricted range of integers
 (due to the use of float for numbers). It would be eventually possible
 to use 64 bits version, but this would restrict Pd with HD support to
 high end platforms (and I like the idea of running Pd on small 32 bits
 platforms)

 Note that HD can be transported over normal MIDI (and MIDI can be
 transported over HD too :-) ), so it's also possible to use this as a
 solution... but knowing that shortest HD message is 3 atoms long (12
 bytes...), this would quickly lead to messy patches to handle HD in
 current Pd.

 So, here is my question : what would Pd community think of including 32
 bits native support in Pd? I know that it would mean a HUGE change in
 the code (basically it's implementing a new type!) but I would not like
 to see Pd being pushed out of HD just because it would be painful to
 implement 32 bits message

 Benoit

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



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


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

Re: [PD-dev] while loop segfault

[Martin Peach]

Not sure why it segfaults, just want to say that that method is really bad.
Because of Pd's control rate as well as the serial interface latency, your
timing will be really sketchy. The way to do what you want is to implement
the ranging entirely on the arduino and send the values back to Pd via
[comport]. So a Pd [pulseIn] object shoud simply send a request to the
arduino to start a pulse and return the time. It could be implemented as an
abstraction containing [comport].

Martin

On Mon, Oct 13, 2014 at 9:29 PM, Colet Patrice colet.patr...@free.fr
wrote:

 Hello, I'm trying to implement the pulseIn() function we can find in
 arduino libraries into an external.

 I couldn't make it work because some part doesn't seem to behave like I
 expect so I'm wondering if it's caused by puredata process,
 so maybe someone in the list could enlight me about that.

 The purpose of the external is about using an ultrasound sensor connected
 on gpio that require a microsecond timer for getting distance like this:


 //here is a custom timer using a struct provided by pcduino headers:
 #include core.h
 unsigned long pat_micros() {
 struct timeval tv;
 gettimeofday(tv,NULL);
 return tv.tv_sec*(uint64_t)100+tv.tv_usec;
 }

 //here is the custom pulseIn() function:
 unsigned long pat_pulseIn(t_pdpcduino *x, int pin)
 {
 unsigned long timeout = 10;
 unsigned long start = pat_micros();

 while( pdpcduino_gpio_read2 (x, pin) == 1 )
 if( pat_micros() - start  timeout )
 return 0;

 // this is where I'm getting a segmentation fault:

 while ( pdpcduino_gpio_read2 (x, pin) == 0 )
 if( pat_micros() - start  timeout )
 return 0;

 //...
 unsigned long value = pat_micros();

 while( pdpcduino_gpio_read2 (x, pin) == 1 )
 if( pat_micros() - start  timeout )
 return 0;

 return pat_micros() - value;

 }

 //...


 If I reduce the timeout number, segfault comes randomly after this
 function has been triggered, so I'm wondering if this method is really
 appropriate,
 is there an exemple of external (containing such while loops) I could get
 inspired from to write this pulseIn() function?






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

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

Re: [PD-dev] building pdlua (was Re: [PD] pdlua)

[Martin Peach]

On 2014-07-22 06:19, IOhannes m zmölnig wrote:

here's another makefile for pdlua, that is based on the most recent
template/Makefile.

it's supposed to be dropped into loaders/pdlua/
(rather than (loaders/pdlua/src/)

the main differences between the old Makefile (which could still
co-exist, as it lives in another directory) are:
- uses LUA_CFLAGS and LUA_LIBS to override *only* the compiler/linker
flags for the system-installed lua
- has all standard build targetes do something useful.
esp. make install and make dist
the only target that is not working is dpkg-source (which imho ,
shouldn't be working anyhow)

to make PdX switch to the new makefile, a few amendments are required
(which i can provide, once this Makefile has been accepted)



I added the Makefile to /trunk/externalsloaders/pdlua/ in svn.
The problem I get is that it looks for lua.h in /usr/include/lua but my 
debian system put lua.h in /usr/include/lua5.1. I know if you get lua 
independently of debian it will go into /usr/include/lua. What is the 
best way to resolve this path for the different versions and different 
packages? Is a configure script needed to set LUA_CFLAGS and LUA_LIBS?



Martin



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