Re: [PD] Ability to access error messages from patch

[Martin Peach]

On Mon, Jun 14, 2021 at 11:03 AM Christof Ressi  wrote:
>
> 1) is
> probably a more pragmatic approach that doesn't require any code to be
> changed and still covers all Pd objects _and_ externals that employ
> 'post'.
>
> I mean, it's probably fine for display purposes, but the help file should 
> clearly state:
>
> "do NOT parse the textual content of error message. EVER. SERIOUSLY"
>
> Parsing error messages is like a house of cards that can collapse anytime.

Also they would tend to fill up the symbol table with junk.
If an error is really an error, it's not fixable from within the patch
anyway. An object that encounters a showstopper error can call
pd_error() instead of post() to print to the console, The user can
then "find last error' and the object will be highlighted. Then they
can plug the cable back in or whatever.


Martin



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

Re: [PD] panning window (touchscreen) with [hsc/sys_gui] on Linux

[Martin Peach]

On Sun, Jun 13, 2021 at 5:55 AM Ingo  wrote:
>
>
> I tried endless variations like e.g.
>
\> [xscroll 5 units .x19889478(= [xscroll 5 units
window_name] or -xscroll or xscrollcommand, etc.
> |
> [hcs/sys_gui]
>
>
I'm no Tcl/Tk expert but I wold naively assume that 'units' is implied
and isn't part of the command, so just {xscroll 5 .x19889478( ought to
work,

Martin



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

Re: [PD] UDP server with Pd

[Martin Peach]

On Tue, Jun 8, 2021 at 12:08 PM Roman Haefeli  wrote:
>
> On Mon, 2021-06-07 at 23:51 +0200, Roman Haefeli wrote:

>
> A quick follow-up. The new object [udpsrvr] works flawlessly. I
> couldn't find any issues with it. I've used it to relay packets between
> multiple clients.
>
> However, my hope a Pd implementation is faster than the python script
> turned out to be forlorn. In reality, the Pd version eats ~50% more
> cycles (at least same ballpark, which is still impressive for Pd, I
> think).

In the last commit I added a verbosity method so it doesn't print to
the console by default. This may speed it up a bit.
OTOH I added an symbol output of the IP so it can be fed directly into
the [to( message, so that may slow it down if the symbol lookup takes
a long time.

Martin



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



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

Re: [PD] UDP server with Pd

[Martin Peach]

So I changed it to use sendto and it works a lot better. It receives
from multiple clients while sending to any one.
I added a [to ( message to set the destination, and removed the
[connect( and [disconnect{ methods.
Thanks Christof for the critique!.

Martin

On Mon, Jun 7, 2021 at 4:02 PM Christof Ressi  wrote:
>
> > The only problem I see with it is that while the socket is connected
> > for a send, it won't receive anything.
> Why is that? This shouldn't happen.
>
> BTW, you don't actually have to call connect(), instead you could just
> save the sockaddr and use sendto(). Consequently you could also rename
> the [connect( method to something else, e.g. [set  ( or
> [client  (, etc. After all, a server doesn't *connect* to a
> client...
>
> Christof
>
> On 07.06.2021 21:34, Martin Peach wrote:
> > OK, I have implemented something that might work: [udpsrvr] can listen
> > on a port and send to an address using the same or a different port.
> > The only problem I see with it is that while the socket is connected
> > for a send, it won't receive anything. I overcome this partly by
> > sending the connect/send/disconnect sequence in one comma-delimited
> > message.
> > The code is at
> > https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/net/udpsrvr.c
> >
> > Martin
> >
> > On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli  wrote:
> >> On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
> >>>
> >>> If you have a [udpreceive 9898] as your 'server' it will receive from
> >>> anywhere on port 9898. So you can take the sender's ip and port from
> >>> the latest incoming message (route 'from' at the second outlet) and
> >>> use them to set the address and port of a single [udpsend] for the
> >>> reply.
> >>> There is no connection in udp so you need to add metadata in your
> >>> datagrams for routing and so forth.
> >>
> >> Again, this does not work. The socket on the client side will only
> >> accept packets originating from the port it has sent packets to, but
> >> [udpsend] on the server cannot use this port as bind port, because it
> >> is already occupied by [udpreceive]. To put this into telephone
> >> analogy: When you call someone, you expect a third party to be
> >> prohibited from shouting into your call, and you expect to hear only
> >> the party you called.
> >>
> >> The only solution to this is to use the same socket for both sending
> >> and receiving, as Christof already suggested.
> >>
> >> Roman
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] UDP server with Pd

[Martin Peach]

On Mon, Jun 7, 2021 at 4:02 PM Christof Ressi  wrote:
>
> > The only problem I see with it is that while the socket is connected
> > for a send, it won't receive anything.
> Why is that? This shouldn't happen.
>
I don't know why, that's what happens when I try it here on linux.
I will see if sendto() works any better. Thanks for the tip.

Martin


> BTW, you don't actually have to call connect(), instead you could just
> save the sockaddr and use sendto(). Consequently you could also rename
> the [connect( method to something else, e.g. [set  ( or
> [client  (, etc. After all, a server doesn't *connect* to a
> client...
>
> Christof
>
> On 07.06.2021 21:34, Martin Peach wrote:
> > OK, I have implemented something that might work: [udpsrvr] can listen
> > on a port and send to an address using the same or a different port.
> > The only problem I see with it is that while the socket is connected
> > for a send, it won't receive anything. I overcome this partly by
> > sending the connect/send/disconnect sequence in one comma-delimited
> > message.
> > The code is at
> > https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/net/udpsrvr.c
> >
> > Martin
> >
> > On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli  wrote:
> >> On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
> >>>
> >>> If you have a [udpreceive 9898] as your 'server' it will receive from
> >>> anywhere on port 9898. So you can take the sender's ip and port from
> >>> the latest incoming message (route 'from' at the second outlet) and
> >>> use them to set the address and port of a single [udpsend] for the
> >>> reply.
> >>> There is no connection in udp so you need to add metadata in your
> >>> datagrams for routing and so forth.
> >>
> >> Again, this does not work. The socket on the client side will only
> >> accept packets originating from the port it has sent packets to, but
> >> [udpsend] on the server cannot use this port as bind port, because it
> >> is already occupied by [udpreceive]. To put this into telephone
> >> analogy: When you call someone, you expect a third party to be
> >> prohibited from shouting into your call, and you expect to hear only
> >> the party you called.
> >>
> >> The only solution to this is to use the same socket for both sending
> >> and receiving, as Christof already suggested.
> >>
> >> Roman
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] UDP server with Pd

[Martin Peach]

OK, I have implemented something that might work: [udpsrvr] can listen
on a port and send to an address using the same or a different port.
The only problem I see with it is that while the socket is connected
for a send, it won't receive anything. I overcome this partly by
sending the connect/send/disconnect sequence in one comma-delimited
message.
The code is at
https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/net/udpsrvr.c

Martin

On Mon, Jun 7, 2021 at 3:48 AM Roman Haefeli  wrote:
>
> On Sun, 2021-06-06 at 20:26 -0400, Martin Peach wrote:
> >
> >
> > If you have a [udpreceive 9898] as your 'server' it will receive from
> > anywhere on port 9898. So you can take the sender's ip and port from
> > the latest incoming message (route 'from' at the second outlet) and
> > use them to set the address and port of a single [udpsend] for the
> > reply.
> > There is no connection in udp so you need to add metadata in your
> > datagrams for routing and so forth.
>
>
> Again, this does not work. The socket on the client side will only
> accept packets originating from the port it has sent packets to, but
> [udpsend] on the server cannot use this port as bind port, because it
> is already occupied by [udpreceive]. To put this into telephone
> analogy: When you call someone, you expect a third party to be
> prohibited from shouting into your call, and you expect to hear only
> the party you called.
>
> The only solution to this is to use the same socket for both sending
> and receiving, as Christof already suggested.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] UDP server with Pd

[Martin Peach]

On Sat, Jun 5, 2021 at 3:31 AM Roman Haefeli  wrote:
>
> On Fri, 2021-06-04 at 19:09 -0400, Martin Peach wrote:
> > On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli 
> > wrote:
> > > On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
> > > > Instead of waiting for
> > > > https://github.com/pure-data/pure-data/issues/949
> > > > - which will probably take months -,
> > >
> > > I am exploring stuff, partly out of curiousity. There is no
> > > expectation
> > > of anything to happen in certain time.
> > >
> > > > you could make a feature request to
> > > > iemnet ;-)
> > >
> > > I just did:
> > > https://git.iem.at/pd/iemnet/-/issues/7
> >
> > Or you could copy the code from mrpeach/udpsndrcv into your own
> > external.
>
> To me,  [mrpeach/udpsndrcv] looks more similar to [iemnet/udpclient]
> than to [iemnet/udpserver]. Both, [mrpeach/udpsndrc] and
> [iemnet/udpclient] require the bind port to be closed before creating a
> new connection. [udpserver] would (ideally) keep the bind port open at
> any time and still be able to set an address (destination address and
> port) for sending.
>

If you have a [udpreceive 9898] as your 'server' it will receive from
anywhere on port 9898. So you can take the sender's ip and port from
the latest incoming message (route 'from' at the second outlet) and
use them to set the address and port of a single [udpsend] for the
reply.
There is no connection in udp so you need to add metadata in your
datagrams for routing and so forth.
Martin



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

Re: [PD] UDP server with Pd

[Martin Peach]

On Fri, Jun 4, 2021 at 6:16 PM Roman Haefeli  wrote:
>
> On Fri, 2021-06-04 at 23:27 +0200, Christof Ressi wrote:
> > >
> > Instead of waiting for
> > https://github.com/pure-data/pure-data/issues/949
> > - which will probably take months -,
>
> I am exploring stuff, partly out of curiousity. There is no expectation
> of anything to happen in certain time.
>
> > you could make a feature request to
> > iemnet ;-)
>
> I just did:
> https://git.iem.at/pd/iemnet/-/issues/7

Or you could copy the code from mrpeach/udpsndrcv into your own external.

Martin


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



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

Re: [PD] UDP server with Pd

[Martin Peach]

On Wed, Jun 2, 2021 at 12:09 PM Christof Ressi  wrote:
>
> On 02.06.2021 16:55, Martin Peach wrote:
>
> > On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli  wrote:

> > You could still have the server reply to the source port plus one, or
> > something like that,
> This doesn't solve anything regarding firewall + NAT.

What is/are the issue{s} with firewall + NAT? Asking because I never
used either, I only ever use them on a  LAN.

> > Usually I have the client include its replyto port in a message.
>
> But why? UDP sockets are already bidirectional. If you need to receive
> replies from the other end, just use the appropriate object, i.e.
> [iemnet/udpclient] or [netsend -u -b].

So the client can dictate which port it wants to listen on.

>  There is some persistent misunderstanding that UDP sockets can
> only be used in one direction. I think one reason is that many creative
> coding environments only provide very basic and limited networking
> objects, so users without a background in network programming think
> that's the way it should be done. In the "real world", a UDP server
> would simply send the reply to the source IP address + port obtained
> with recvfrom() while a TCP server would send its message to the client
> socket it received the message from. It's ironic that Pd doesn't provide
> an easy way for such a common task... 

I think as far as the Pd net objects (netsend] and [netreceive] go,
it's because they were conceptually based on Pd's [send] and
[receive]. I mutated [netsend] and [netreceive] into [udpsend] and
[udpreceive] in order to be able to pass raw bytes instead of FUDI
messages, so that the [packOSC] and [unpackOSC] objects could work
with them. The more recent [udpsndrcv] is more aligned with [comport]
in being bidirectional.
The main persistent misunderstanding I find with UDP is the connection
-- it doesn't exist. Hitting [connect( doesn't do anything on the
network, it only sets the address for subsequent sends. So sending the
first datagram after 'connecting' may take longer as the OS may need
to find the route to that address on the network by sending other
packets.


Martin



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

Re: [PD] UDP server with Pd

[Martin Peach]

OK, I found it now...The object is [udpsndrcv] in mrpeach.
It allows you to set the source and destination  ports and send and
receive on them.

Martin

On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli  wrote:
>
> (replying to list as - I believe - you intended to)
>
> On Wed, 2021-06-02 at 09:34 -0400, Martin Peach wrote:
> > On Wed, Jun 2, 2021 at 3:31 AM Roman Haefeli 
> > wrote:
> > > On Tue, 2021-06-01 at 19:19 -0400, Martin Peach wrote:
> > > > A [udpsend] normally has a different port number to the one it
> > > > sends
> > > > to, but a [udpreceive] in the same Pd process can still receive
> > > > on
> > > > that port.
> > >
> > > My understanding is that a client won't accept messages with a
> > > different source port than it has sent to. Also, such packets
> > > wouldn't
> > > be able to traverse NAT firewalls.
> > >
> >
> > A udp packet almost always has a different source port from its
> > destination. It's not the same as TCP as there is no real
> > "connection"
> > established or maintained, it's just fire and forget. I modified the
> > udp objects in response to a request to do just that: send back to
> > the
> > same port.
>
> You're absolutely right. I think my wording was not clear. Sorry for
> that.
>
> When a client with bind port 52333 sends a packet to the server
> listening on port 5000, it won't accept response packets from the
> server with (matching) destination port 52333 and (different) source
> port 5001. [udpsend] on the server side cannot use bind_port=5000,
> because it is already used by [udpreceive]. And from what I see in the
> documentation, [udpsend] doesn't support setting a bind port, it seems
> to pick a random one (which is the normal thing to do when acting as a
> client, but not sufficient for a server response to a client request).
>
> So, I believe my goal can (so far) only be achieved with [netsend
> -u]/[netreice -u] as Miller suggested.  Mission accomplished.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] UDP server with Pd

[Martin Peach]

On Wed, Jun 2, 2021 at 9:58 AM Roman Haefeli  wrote:
>
> (replying to list as - I believe - you intended to)
>
> On Wed, 2021-06-02 at 09:34 -0400, Martin Peach wrote:
> > On Wed, Jun 2, 2021 at 3:31 AM Roman Haefeli 
> > wrote:
> > > On Tue, 2021-06-01 at 19:19 -0400, Martin Peach wrote:
> > > > A [udpsend] normally has a different port number to the one it
> > > > sends
> > > > to, but a [udpreceive] in the same Pd process can still receive
> > > > on
> > > > that port.
> > >
> > > My understanding is that a client won't accept messages with a
> > > different source port than it has sent to. Also, such packets
> > > wouldn't
> > > be able to traverse NAT firewalls.
> > >
> >
> > A udp packet almost always has a different source port from its
> > destination. It's not the same as TCP as there is no real
> > "connection"
> > established or maintained, it's just fire and forget. I modified the
> > udp objects in response to a request to do just that: send back to
> > the
> > same port.
>
> You're absolutely right. I think my wording was not clear. Sorry for
> that.
>
> When a client with bind port 52333 sends a packet to the server
> listening on port 5000, it won't accept response packets from the
> server with (matching) destination port 52333 and (different) source
> port 5001. [udpsend] on the server side cannot use bind_port=5000,
> because it is already used by [udpreceive]. And from what I see in the
> documentation, [udpsend] doesn't support setting a bind port, it seems
> to pick a random one (which is the normal thing to do when acting as a
> client, but not sufficient for a server response to a client request).
>

You're correct. I thought I had fixed that a few years back but I
guess I hadn't.
You could still have the server reply to the source port plus one, or
something like that,
Usually I have the client include its replyto port in a message.

Martin

> So, I believe my goal can (so far) only be achieved with [netsend
> -u]/[netreice -u] as Miller suggested.  Mission accomplished.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] UDP server with Pd

[Martin Peach]

The mrpeach [udpsend] outputs its ip and port on the second outlet on
'connect', while the[ [udpreceive] object outputs the ip and port of
each received datagram, so using both you should be able to do what
you want.
A [udpsend] normally has a different port number to the one it sends
to, but a [udpreceive] in the same Pd process can still receive on
that port.

Martin

On Tue, Jun 1, 2021 at 4:57 PM Roman Haefeli  wrote:
>
> Hey all
>
> I would like to open a datagram listening socket and be able to send
> back to clients from which I received messages. It seems both [netsend
> -u] and (obviously) [netreceive -u] actually can open a listening
> socket. However, [netreceive -u] can't send anything back. While
> [netsend -u] can send messages back, it doesn't show the source address
> of the incoming packets. And using [netreceive -u] for receiving and
> [netsend -u] for sending back doesn't work, because for the packets to
> arrive at the client, they need to be sent from the same port that is
> already occupied by [netreceive].
>
> Yet, as long as I used TCP and iemnet, this was possible. However, as
> far as I can tell, it's not possible with UDP, neither with iemnet nor
> with Pd's built-in classes.
>
> Is that something worth to make a feature request for?
>
> While we're at it, it seems [netreceive] (in TCP mode) can only send
> back to all connected clients, but not to a specific one.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] how to get big numbers from array into a file?

[Martin Peach]

On Fri, May 7, 2021 at 11:23 AM Christof Ressi  wrote:
>
> Thanks for stressing the differences between 64bit and double precision!

The confusion persists though, as double precision is also 64-bit. One
has 64-bit address bus width and the other has 64-bit data bus width.
'64-bit Pd' appears to refer to the wide address version. So I guess
the wide data version is called 'double-precision Pd'? (although it
will also use the wide address bus)(the meaning of 'double precision'
is too ambiguous for me as it will change over time in a way that '64'
hopefully doesn't)
Does the 'double-precision Pd' also save its patches to 6 significant digits?
It is possible to write an external in 'normal' Pd that manipulates
numbers in whatever precision you like, you just can't save the
results unless you do so from within the same external.

Martin



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

Re: [PD] how to get big numbers from array into a file?

[Martin Peach]

On Fri, May 7, 2021 at 10:17 AM  wrote:
>
> hi,
>
> i'm struggling with the way Pd handles numbers bigger then 99.
>
> i have an array with thousands of numbers, which i write to a file to analyse 
> them.
>
> however, as soon as a number is bigger then 99 i get the abbreviated 
> notation and am loosing the lower digits.
>

This is because Pd rounds all numbers to six significant digits when
it writes hem to a file.
You could try using two arrays with the most and least significant
halves of the numbers in parallel.
Or wait for 64-bit Pd

Martin



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

Re: [PD] ignore hidden files from hcs/folder_list

[Martin Peach]

On Tue, May 4, 2021 at 10:41 AM Dan Wilcox  wrote:
>
> I'm interested in more info about this behavior. I'm only aware of macOS 
> Finder creating .DS_Store files and temp directories so Spotlight can index 
> and show media playback via Quick Look. Is something creating hidden temp 
> files in the same directory as the audio files themselves or are these in a 
> subdirectory?

I run into this all the time with people (our students) using
standalone audio file players using micro SD cards, such as the
Tsunami wav trigger. The board silently fails to play any files. The
students made the files with Audacity on their Mac laptops. When the
card is read on a WIndows or linux machine it shows a duplicate list
of files all prefixed with the dot. Once these are erased from the
card the player will function normally. There's usually some .DS_Store
stuff as well.
Of course on a Mac these files are all invisible, so you can't erase
them on the Mac itself (and they'll probably get recreated anyway).

Martin




Martin



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

Re: [PD] 4-point interpolation changes timbre depending on sample rate

[Martin Peach]

I think there's a niche for some kind of sinc convolver to be used in
bandlimiting arbitrary waveforms.

Martin

On Mon, May 3, 2021 at 9:26 AM Clemens Wegener  wrote:
>
> I think now would be a good place to pause the implementation and discuss
> if there is a need for this kind of algorithm in the PD community.
>
> We saw some use cases for the Whittaker-Shannon interpolation where
> we gain in quality and/or speed. Namely waveguides and pitch shifters.
>
> Is there anything else, where we would like to use this interpolation kernel?
> Like in general resampling?
> In the tabread~ for sample playback?
> Are there really quality or speed issues that we could solve there?
>
> For our use case the code I submitted is good enough. But I would be happy
> to spend more time optimizing if there is a need / a broad use of that 
> algorithm.
> In that case we need another restructuring and some help from somebody
> who is very proficient in writing pd source code. :)
>
> Chuck, I commented your last message below!
>
> Am 2021-05-03 um 03:52 schrieb Charles Z Henry :
>
> On Sun, May 2, 2021 at 4:28 PM Clemens  wrote:
>
>
> When there is no aliasing to worry about, i might set the cutoff to pi
> again...
> On low sample rates (22kHz), the lower cutoff is definitely noticeable.
>
>
> I like this thesis you posted earlier
> https://www2.spsc.tugraz.at/www-archive/downloads/Mueller11_DopplerSRC_0.pdf
>
> f(at) <-> 1/|a|*F(w/a)
> This (and two formulas that follow) is listed as Smith's algorithm.  I
> actually got to speak with Julius Smith at the 2012 LAC about this
> formula.  I asked, can't we do any better in terms than O(a*n) number
> of computations for a>1?  He said nope!, but I still have some
> questions there.  Playback with speeds less than 1 always use O(n),
> rather than O(a*n).  I wrote an anti-aliasing external tabread4a~ that
> implements this formula per sample and works pretty well, except it
> becomes expensive when you transpose a few octaves up.
>
>
> I guess that’s the code you are referring to (?):
> https://lists.puredata.info/pipermail/pd-list/2007-03/048397.html
>
> Is it using a lookup of the sync table at certain fixed points?
> If so, would it be „compatible“ in the sense that these points are part
> of the lookup table in delreadsinc~?
>
>
> For a variable delay line (like vd~), the paper's contents are more
> relevant and maybe you should consider writing a vdsinc~ object next
> (once you've optimized this one).  delread is more like a fixed,
> stationary delay line, and I think it's better to default as a literal
> interpolator (LP_SCALE = 1).
>
>
> Ok. That’s what I thought as well. Still I would need to read a bit more
> about the subject to understand how the variable delay case relates to
> down-/upsampling. In tabread4a~ you derive the sampling factor from
> the difference in delay time, right?
>
>
> Btw. I just implemented sharing of the interpolation table of the
> delreadsinc~ object according to your suggestions.
> It counts the number of references and frees the pointer when no object
> uses it anymore.
>
>
>I read through the changes.  For those reading along see the rest
> at line 348 of d_delay.c at
> https://github.com/chairaudio/pure-data/blob/feature/delreadsinc/src/d_delay.c
> (in progress, current code re: the tables pasted below).
>1. I wonder is this global table properly scoped for Pd.  I
> seriously don't know.  But it could be used for multiple objects,
> vdsinc~, tabreadsinc~, etc So you ought to think about how it
> could be re-used between classes and choose a scalable approach now.
>
>
> Good question. :) I’m not sure if Miller has suggestions or examples how
> global variables are handled in PD.
>
>2. I think the declared LP_SCALE variable is a bad approach as
> currently implemented.  You can't change it at runtime.  It can be
> used in the perform routine instead, with an additional argument to
> set the cutoff frequency per object.  This is also good for your
> testing, as you'll be able to put objects with different LP_SCALE
> values side-by-side for comparison.
>
>
> That’s right, LP_SCALE should be tunable in real-time.
> I think that would need only little change to the code.
>
>3. I'm convinced this is the right approach for making an optimal
> interpolator.  Adding more length pays off over upsampling, because
> you evaluate the convolution at a fewer number of points.  Your
> implementation needs a lot of tuning---you can squeeze out more
> performance.  Focus on the inner most loops.  Also, you'll have to
> compare some arm vs intel/amd platforms at some point.  I think you're
> closer to the beginning than the end.  This is maybe not what you
> wanted to research in the first place
>
>
> When it gets down to processor specific optimization, I’m not sure how
> much the compiler does already and if it’s really worth the effort.
> I would investigate this if we find that we want to put this code into pd.
>
> Best wishes,
> Clemens

Re: [PD] OSC limitations in Vanilla

[Martin Peach]

On Mon, Apr 19, 2021 at 6:51 PM Christof Ressi  wrote:
>
> so what i'm really suggesting to "fix" the timestamps in [packOSC] is to use 
> logical time for *advancing time* (and add some offset to put the timestamps 
> into the same calendar as NTP)
>
> This corresponds to 2) in my previous mail. While this sounds simple in 
> theory, in practice you will encounter problems with clock drift sooner or 
> later. Supernova had to introduce an option to use the system time instead of 
> the logical time because some users had experienced issues. For a drastic 
> example, search for "timing drift supernova" in 
> https://www.listarc.bham.ac.uk/lists/sc-dev-2014/search/
>

You probably need some kind of 'resync' messages sent
quasi-periodically, but when?
I have implemented in [packOSC] acquiring the OS's clock time when the
first instance of [packOSC] starts up, by sing a global variable for
the start epoch.
All subsequent timestamps are generated using that offset plus Pd's
DSP clock, so all [packOSC]s in a patch will generate the same timetag
for the same DSP tick.
So the question is, how to do the resync when the drift gets out of hand?
I do think that any fancy timing stuff should be done outside of
[packOSC] and the [timetagoffset( message be used to stay in sync.

Martin



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

Re: [PD] OSC limitations in Vanilla

[Martin Peach]

On Sun, Apr 18, 2021 at 6:06 AM IOhannes m zmölnig  wrote:
>
> I don't really like the timestamp implementation in mrpeach (as it uses real 
> time, rather than logical time), but better this than nothing...

Logical time timestamps would only be accurate inside of the Pd
instance. It could be added as an option but it would not conform to
any OSC specification.

Martin



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

Re: [PD] pd~ -nogui process with Gem [scopeXYZ]

[Martin Peach]

Hi Samuel,
I think you have it backwards -- you should run the audio in [pd~] as
it already has no GUI. And if you don't care about latency (it sounds
like you're using prerecorded or generated dmaterial), just increase
the audio block size until you don't get dropouts.

Martin

On Sun, Apr 11, 2021 at 11:23 AM Samuel Burt
 wrote:
>
> Here's what I'm trying to do:
> On a Raspberry Pi 3, I want to run an audio patch that generates LFOs and 
> also have a Gem window that shows [scopeXYZ]. There are tremendous dropouts 
> unless [scopeXYZ] has a very short length of samples to process.
>
> Here's one problem I've run into:
> I'm prototyping on Windows 10. I decided to try running the Gem component in 
> a subprocess [pd~]. The [pd~] object doesn't seem to accept the "-nogui" tag. 
> How do I use it? Will it also hide the terminal window that launches the 
> second copy of Pd?
>
> Is this an effective method of separating Gem from audio on a Raspberry Pi? 
> Is there a better way?
>
> Hi. I find it difficult to search for discussions related to pd~ because 
> Google uses ~ for synonym searches.  Any tips for searching for [pd~] on the 
> web and the mailing list?
>
> Thanks!
> Sam
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Pd and computer crash/freeze when using [comport], bug?

[Martin Peach]

I was able to get the files by right-clicking on their icon and doing 'save as'.
In my experience the only way [comport] crashes Pd is when you try to
print its output to the console while it's receiving huge amounts of
data. This causes the messaging pipeline to the TCL process to fill up
until it has no more space, as it is unable to keep up with the
incoming stream..

Martin


On Sat, Apr 10, 2021 at 12:20 PM Alexandros  wrote:
>
> Pduino has nothing to do with [serial_print]. Such a scenario could suggest 
> some problem with Pd when sending data to [comport] and processing data 
> received from it (I'm not suggesting it's a problem with [comport] since 
> disconnecting it from [serial_print] solved the crash problem). I haven't 
> checked your files yet (see my previous reply asking for them via a different 
> medium), so I have no idea what could be wrong with [serial_print]. I'll get 
> back once I have your files and have checked them.
>
> On 10/4/21 11:26 π.μ., Nicklas Lundberg wrote:
>
> Thank you for doing this. It may also be relevant that I experienced the 
> exact same of freeze/crash behavior when using Pduino.
>
>> Date: Fri, 9 Apr 2021 17:14:18 +0300
>> From: Alexandros 
>> To: pd-list@lists.iem.at
>> ...
>> This has to do with the abstraction I made then. We did discuss about it
>> on Pd's forum, but it didn't occur to me that this could be the case.
>> I'll have a look at it and get back to you.
>>
>> On 9/4/21 5:10 ?.?., Nicklas Lundberg wrote:
>> > Hmm, it does not crash when [serial_print any] is disconnected. You
>> > can quit normally.
>> >
>> > This may be relevant:
>> >
>> > Pd console reports no errors when communication fails when trying too
>> > fast updates (with [serial_print any] disconnected less than 30 ms).
>> >
>> > I uploaded a similar setup (pd patch+arduino sketch) to the folder.
>> > Here it does not crash even if updates are sent every 1 ms. And the pd
>> > console starts to write error messages when the communication is too
>> > fast (starts around 7 ms).
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Pd and computer crash/freeze when using [comport], bug?

[Martin Peach]

Does it still crash if you disconnect the [serial_print-any]
abstraction from [comport]?

Martin

On Fri, Apr 9, 2021 at 7:45 AM Nicklas Lundberg  wrote:
>>
>> On Fri, 2021-04-09 at 09:31 +0200, Nicklas Lundberg wrote:
>>
>> > [comport] is communicating with an Arduino Nano over USB to control
>> > PWM pins.
>> >
>> > If [comport] is receiving messages faster than 50 ms Pd will freeze,
>> > has to be force quitted, system gets sluggish, and the computer has
>> > to be restarted.
>> >
>> > I can replicate it and it happens every time. I wonder if this should
>> > be reported as a bug or if it is expected behavior in the specific
>> > setting.
>>
>>
>> While not suggesting that I'd be able to help, can you provide some
>> more information, ideally providing a minimal patch that triggers the
>> behaviour?
>>
>> Also what versions are involved: OS, Pd, comport?
>>
>> Roman
>
>
> Pd/Arduino codes and crash instructions in this folder:
>
> https://drive.google.com/drive/folders/1oDxeFCc63tvdgP6CWguJmBdfekAAMOrQ?usp=sharing
>
> comport 1.1.1
> Pd-0.51-4
> MacOS Mojave 10.14.6
> MacBook Air 11" mid 2012
>
> to crash pd and computer:
> Upload sketch to Ardunio (Nano)
> Open comport serial communication
> activate dsp
> Set metro object to less than 50 ms
> Toggle metro on to crash
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Sending Startbit and Stopbit with comport for MIDI with Arduino

[Martin Peach]

Hi Ingo,
It's not clear to me which parts of your setup are hardware MIDI and
which are hardware serial, so this may be not relevant:
MIDI uses the same serial protocol as regular serial, the difference
is the baud rate (31250 is not a standard baud rate)
At the hardware level, MIDI is optoisolated and works as a current loop.
At the Pd end, MIDI messages are handled completely separately from
whatever [comport] is doing, so you have to 'manually' reconstruct
MIDI from a serial stream (as with [midifile], which also doesn't
integrate with Pd's MIDI sytsem, as MIDI is being handled at the
driver level, and uses a different software interface).

So if your baud rate on the Arduino is 31250, at the minimum you need
[comport] to be running at 31250 s well, which is not usually
possible.
It's easier to use a MIDI interface on the computer and send MIDI from
the arduino directly. This can be done using 2 220 Ohm resistors and a
DIN-5 connector.

Martin






On Mon, Mar 22, 2021 at 4:13 AM Ingo  wrote:
>
> Hi,
>
> I would like to send MIDI with [comport] from Pd by using an Arduino.
>
> Reading into Pd is no problem.
> It also works fine as a MIDI Thru by simply forwarding the Serial1 RX input
> (MIDI input) to the Serial1 TX output (MIDI Thru).
> Something like this:
>
>   if (Serial1.available() > 0) {
> Serial1.write(Serial1.read());
>   }
>
> (The loop duration is only about 250 盜 so there is no timing problem in
> this case.
> For data coming in faster than the loop duration I would probably have to
> read into an arry first.)
>
>
> However, if I'm sending a MIDI message from Pd it's not recognized by the
> connected MIDI interface.
> I'm assuming that's probably because there is no startbit and stopbit that
> the MIDI interface is looking for.
>
> According to the helpfile I can send a stopbit with [comport] but I didn't
> find anything about a startbit.
>
> Is there a possibility within Pd and [comport] to send a startbit or would
> it make more sense to add the startbit and stopbit within the Arduino
> programming?
>
> Thanks!
> Ingo
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Pduino 0.7 compatibility with Pd vanilla

[Martin Peach]

I'm not sure if I'm totally up to date here but with a nano on
Windos10 I also get no pin 7 reported.
ARDUINO_INFO: version 2 5
ARDUINO_INFO: firmware StandardFirmata.ino 2 5

A pin like D2 willl report:
comport receives from the arduino: 144 120 1  (b0000) (b0001)
convert_to_symbolic_commands outputs: digital 2 0
ARDUINO_OUT: digital 2 0

comport receives from the arduino: 144 124 10 (b0100) (b0001)
convert_to_symbolic_commands outputs: digital 2 1
ARDUINO_OUT: digital 2 1

But piin 7 is like this:
comport receives from the arduino: 144 124 0 (b0100) (b)
comport receives from the arduino: 144 124 1 (b0100) (b0001)

This appears to be because the state of pin 7 is in the second data
byte, which is ignored by the [pd convert_to_symbolic_commands ].

Bits 8 and up work because they are in the next port, so they appear
as bits 0-7, so probably Pin 15 also doesn't work.

The code in firmatamarshaller.cpp refers to two versions:
  FirmataStream->write(DIGITAL_MESSAGE | (portNumber & 0xF));
  // Tx bits  0-6 (protocol v1 and higher)
  // Tx bits 7-13 (bit 7 only for protocol v2 and higher)
  encodeByteStream(sizeof(portData), reinterpret_cast(), sizeof(portData));
.

...so possibly pduino is not yet compatible with version2.

Martin





On Sat, Mar 20, 2021 at 6:15 PM Roman Haefeli  wrote:
>
> On Sat, 2021-03-20 at 21:53 +0100, Roman Haefeli wrote:
> > On Sat, 2021-03-20 at 19:24 +0100, Gilles Marivier wrote:
> > > :
> > > > https://github.com/pd-externals/pduino/issues
> > >
> > > Done !
> > >
> > > I forgot a point : all others pins work fine on Nano
> >
> > Thanks, yeah, I saw it. However, I can't make any promises, though,
> > since I don't own a Nano (in case that problem is specific to the
> > Nano,
> > which is not yet clear).
>
> Ok, this particular problem is fixed in current master. It turns out
> the buggy code had 8 copies! So always the last pin in a group of 8 (7,
> 15, 23, etc.)  did not return anything.
>
> I believe this digital input mess could be done in a better, more
> robust way with less code duplication.
>
> Also, with the Arduino Leonardo and Firmata 2.5, the higher numbered
> pins (the "analog pins") do not report with pduino when set as digital
> inputs.
>
> It looks like some refactoring of that old code is warranted.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] How can I send numer 0-255 to an ardino?

[Martin Peach]

On Mon, Mar 15, 2021 at 1:36 PM Ingo  wrote:
>
> Hi there,
>
> I'd like to send integers 0-255 to an Arduino with comport.
>
> For text I use [asqseq] to convert it to the ascii numbers that the Arduino
> uses.
> However, I don't know how to send plain integers that come in as the same
> numbers on the Arduino.
>

[comport] accepts Pd floats as input, if those floats are also
integers on 0-255, so you can send directly from a numberbox or
similar. At the arduino end, Serial.read() also outputs bytes on
0-255, so you don't need to translate to and from ascii at all.

Martin



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



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

Re: [PD] OT: Very Old MIDI Keyboard Big Sur

[Martin Peach]

On Sun, Mar 14, 2021 at 7:47 AM mitchell turner  wrote:
>
> I know this is way off topic, but I’m hopeful one of you was in a similar 
> situation and has a solution.
>
> I run a mac lab for my music program. We are getting new iMacs with Big Sur 
> (11.2). I have several (very old) M-Audio MIDI keyboards that I am unable to 
> get running with Big Sur. These Keystation and Radium keyboards are likely 
> 10-15 years old. They are not class compliant and require drivers. 
> Unfortunately, it does not appear M-Audio is going to produce legacy drivers.
>
> I’m wondering if anyone has been able to get old MIDI keyboards working on 
> Big Sur? Is there a bridge program, generic driver, etc.?
>

Why not use the MIDI outs on those keyboards? MIDI to USB converters
are not obsolete.

Martin



> Any help would be appreciated.
>
> — Mitch
>
> 
> Mitchell Turner, PhD
> Professor of Music
> LaGrange College
> 601 Broad Street
> LaGrange, GA 30240
> USA
>
> Office: 706-880-8015
> mturner (_AT_) lagrange (_D0T_) edu
>
> class/program links:
> http://home.lagrange.edu/mturner/
> http://home.lagrange.edu/mturner/classes.html
> http://home.lagrange.edu/mturner/musicdept.htm
> http://www.facebook.com/lagrangemusic
> 
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] PD 64 bits precision "for real"?

[Martin Peach]

On Tue, Nov 24, 2020 at 5:07 AM jayrope  wrote:
>
> Why do we need _any_ name change?
> Any obvious version jump would do it already, 0.6, no?

A 64-bit Pd would not be compatible with any previous version because
all the memory structures would be differently sized, so any externals
built for previous versions would crash. While any patches using
vanilla objects would still work, unless a 64-bit version had some way
of running 32-bit externals in parallel, it would be effectively a
different program, not just a new version.

Martin



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

Re: [PD] Pd 64 bits precision "for real"?

[Martin Peach]

or dippidydoo, dpd2

On Mon, Nov 23, 2020 at 7:24 AM Dan Wilcox  wrote:
>
> I think "pd64" is fine, otherwise the list get's catchy/dumb:
>
> pdpd (haha)
> pd two-times
> pd again
> pd double trouble
> pd dubs'
> pd-sharp (less rounding)
> ...
>
> I would fine "dppd" confusing unless we go ahead and re-brand ala "pd 
> vanilla" and "double-dipped pd" aka "dppd"...
>
> On Nov 23, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
>
> Message: 1
> Date: Mon, 23 Nov 2020 09:22:49 +0100
> From: IOhannes m zmoelnig 
> To: pd-list@lists.iem.at
> Subject: Re: [PD] Pd 64 bits precision "for real"?
> Message-ID: <57e459d6-e8d1-516c-da37-af88912aa...@iem.at>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 11/23/20 12:25 AM, Martin Peach wrote:
>
> It should be named dppd to avoid confusion imho.
>
>
> or pddp (or is that already taken?)
>
> when csound switched to double precision they renamed things to
> "csound64" (with "things" being at least the libraries that hold the
> engine).
>
> so i like pd64 better, as it is obvious that this is still Pd (and not
> just some nice palindromic acronym).
>
> but anyhow, yes: we probably need a catchy name.
>
> fgmadsr
> IOhannes
>
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Pd 64 bits precision "for real"?

[Martin Peach]

It should be named dppd to avoid confusion imho.

Martin

On Sun, Nov 22, 2020 at 6:15 PM Alexandre Torres Porres
 wrote:
>
> so, here I ask, could we expect a 64 bit precision Pd for download in the 
> next release if that PR gets in? Is it just waiting to be merged, now?
>
> Em dom., 22 de nov. de 2020 às 19:42, Christof Ressi  
> escreveu:
>>
>> Double precision Pd indeed solves the table playback issue (among other
>> things).
>>
>> Christof
>>
>> PS: "64-bit Pd" usually means Pd compiled for a 64-bit architecture, but
>> this thread is really about double precision Pd. I'm sure you were
>> talking about the latter, but this is a constant source of confusion, so
>> I thought I'd better make this clear for other readers.
>>
>> On 22.11.2020 23:39, Peter P. wrote:
>> > * Dan Wilcox  [2020-11-20 23:19]:
>> >> Note: until the sound file updates branch with the CAF file support is 
>> >> merged, 64 bit sample indices aren't yet useful with the current core 
>> >> file formats (WAV, AIFF, SND) as they use 32 bit indices.
>> > Dan, is this in any way related with buffer indexing? I am wondering if
>> > with 64bit Pd the B16.long-varispeed.pd workaround with the second inlet
>> > will still be necessary to get cleaner table playback at slow speeds?
>> >
>> > thanks, P
>> >
>> >
>> >
>> > ___
>> > Pd-list@lists.iem.at mailing list
>> > UNSUBSCRIBE and account-management -> 
>> > https://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Startup times to run Pd patch on Raspberry Pi

[Martin Peach]

It takes about a minute for the pi to boot. There is not much you can
do about that.

Martiin

On Mon, Oct 5, 2020 at 11:03 AM Yann Seznec  wrote:
>
> Hi everyone, long time reader first time writer.
>
> I’m wondering what people’s experiences are with regards to the startup time 
> for running a patch on a raspberry pi.
>
> For various reasons I’ve started to use Patchbox OS to auto-run my patches on 
> startup, which is very reliable and consistent however it usually takes about 
> 60 seconds from switching on to making sound. This is on various models of 
> Raspberry Pi 3.
>
> Has anyone managed to speed this up? I haven’t tried the Raspi 4, perhaps 
> that is significantly faster?
>
> Thanks,
> Yann
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] mrpeach/midifile: multiple voices

[Martin Peach]

On Sat, Oct 3, 2020 at 7:15 PM Jakob Laue  wrote:
>
>
> Hi Martin,
> thanks for your quick response!
>
>
>
>
>
> Gesendet: Samstag, 03. Oktober 2020 um 19:02 Uhr
> Von: "Martin Peach" 
> An: "Jakob Laue" 
> Cc: "Pd-List" 
> Betreff: Re: [PD] mrpeach/midifile: multiple voices
> On Sat, Oct 3, 2020 at 7:05 AM Jakob Laue  wrote:
> >
> > Hi list,
> > i have a patch that a melody and saves it into a midifile with [midifile] 
> > from mrpeach.
> > Now i have extended the patch so that there is a second melody generated 
> > which accompanies the first one. Now i also send the pitch/noteduration 
> > pair of the second melody to the same [midifile] object in order to receive 
> > a two-voice-midi-file. But unfortunately both melodies seem to overwrite 
> > their noteDurations and hence i have wrong note durations in the midi file.
> >
>
>
>
> Are you writing a single track with two MIDI channels or two tracks?
>
> ->> to be honest, I can not answer this question. I initialize [midifile] 
> with ...
> - filename and fps in one message
> - time signature message [255 88 4 4 2 38 8)
> - tempo message [255 81 ...(
> ...before I send it events.
>

If the events for the two melodies are in two different MIDI channels
it should work to record them in the default single track. So if you
add the channel number minus one to the MIDI status byte (for example,
144 is note-on status for channel 1, 145 is note-on in channel 2) they
should stay separate.


>
> If you use a [track ( message before each event it should keep them separate.
>
>
> -> Do you mean a track name message like "FF 03 len text Sequence/Track Name" 
> according to 
> http://www.music.mcgill.ca/~ich/classes/mumt306/StandardMIDIfileformat.html 
> at the bottom?
>

No. See under 2.2 - MIDI File Formats 0,1 and 2.
It's possible to make a multitrack midi file by sending, say,  [track
2( to [midifile] before sending an event for track 2, then [track 1(
before a track 1 event. That way you could have several separate
instruments on the same MIDI channel. (This format 1 only writes
correctly in the latest midifile v.041, but all versions should be
able to read any format). Most of the midi files on the web seem to
have one instrument per track, and MIDI channel numbers are not used.
To use [midifile] as a sequencer it's easier to have one track and
several channels. To export a composition as a MIDI file, it should
probably be using several tracks.

Martin



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

Re: [PD] mrpeach/midifile: multiple voices

[Martin Peach]

On Sat, Oct 3, 2020 at 7:05 AM Jakob Laue  wrote:
>
> Hi list,
> i have a patch that a melody and saves it into a midifile with [midifile] 
> from mrpeach.
> Now i have extended the patch so that there is a second melody generated 
> which accompanies the first one. Now i also send the pitch/noteduration pair 
> of the second melody to the same [midifile] object in order to receive a 
> two-voice-midi-file. But unfortunately both melodies seem to overwrite their 
> noteDurations and hence i have wrong note durations in the midi file.
>

Are you writing a single track with two MIDI channels or two tracks?
If you use a [track ( message before each event it should keep them separate.


Martin



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

Re: [PD] [pii2c] keeps and resends previous messages when addresses change

[Martin Peach]

I uploaded a new version of [pii2c] yesterday via deken. It has some
slight changes, (mainly adding optional address to the read message).
I still don't get the double sends. I attach my code for teensy that
listens on all the addresses. When I try your patch with it, the
teensy only receives on the intended address. If I do 'i2cdetect -y 1'
in the terminal it receives on all addresses 0x03-0x77.

Martin


On Wed, Sep 23, 2020 at 11:49 AM Martin Peach  wrote:
>
> Before I test this, I notice you use Wire for the i2c slaves. Wire is
> known to not work properly in slave mode.
> I use this library for teensy i2c, it works very well:
> https://github.com/nox771/i2c_t3
> But I'll try your code later and see what I get.
>
> Martin
>
> On Wed, Sep 23, 2020 at 3:40 AM Alexandros  wrote:
> >
> > Sorry for coming back to this thread after so long, didn't have a Pi at
> > hand. I have attached a very simple patch which reproduces the bug.
> > You'll need to connect two I2C slave Teensy LC to the Pi. I have also
> > attached the two Arduino files that should be loaded to the Teensies.
> >
> > What happens with this setup is that the Teensy that listens to 0x09
> > (i2c_mess2.ino file) receives messages even when something is sent to
> > 0x0A. The Teensy that listens to 0x0A (i2c_mess1.ino file) doesn't seem
> > to be receiving anything.
> >
> > One Teensy prints to the serial console and the other responds by
> > lighting up and turning off the LED on pin 13.
> >
> > On 12/9/20 11:02 μ.μ., Martin Peach wrote:
> > > On Thu, Sep 10, 2020 at 2:25 PM Alexandros  wrote:
> > >> When trying to send messages to two I2C slaves from the Pi with [pii2c]
> > >> the following happens:
> > >>
> > >> If I send this message to [pii2c 0x0A]:
> > >> "write 3 127 7"
> > >>
> > >> it arrives properly at the slave address 0x0A.
> > >>
> > >> If I change the address to 0x09 with the message "addr 0x09" and then
> > >> send this message:
> > >> "write 97"
> > >>
> > >> then both messages will be sent to the respective slaves, meaning that
> > >> "3 127 7" will be sent to slave 0x0A and "97" to slave 0x09. If I then
> > >> change the message sent to 0x09 to "98", this will be sent to 0x09, but
> > >> again "3 127 7" will be sent to 0x0A. If I resend "3 127 7" to 0x0A,
> > >> "98" (the last message set to 0x09) will be sent to 0x09 as well.
> > >>
> > >> The same behavior occurs when I send the message "write 0x09 98". The
> > >> same behavior also occurs if I use two different [pii2c] objects, like 
> > >> this:
> > >>
> > >> [write 3 127 7(
> > >> |
> > >> [pii2c 0x0A]
> > >>
> > >> [write 97(
> > >> |
> > >> [pii2c 0x09]
> > >>
> > >>
> > > Hmmm I don't get this. Do you have a patch that will reproduce the bug?
> > > (I am also able to send messages longer than 32 bytes, with
> > > MAX_I2C_BUF_SIZE 64 in my copy of pii2c.c.)
> > > I used a teeny 3.2 as a slave (using i2c_t3 from
> > > https://github.com/nox771/i2c_t3) listening on all addresses. It only
> > > receives the messages on the addresses I set in the Pd patch.
> > >
> > > Perhaps you have a hidden [pii2c 0x0A] somewhere that is also
> > > receiving your write messages.
> > > Since [pii2c] is using the same memory space for each message any new
> > > message will effectively erase the old ones, so it's hard to explain
> > > two different messages coming from a single object.
> > >
> > > Martin


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

Re: [PD] [pii2c] keeps and resends previous messages when addresses change

[Martin Peach]

Before I test this, I notice you use Wire for the i2c slaves. Wire is
known to not work properly in slave mode.
I use this library for teensy i2c, it works very well:
https://github.com/nox771/i2c_t3
But I'll try your code later and see what I get.

Martin

On Wed, Sep 23, 2020 at 3:40 AM Alexandros  wrote:
>
> Sorry for coming back to this thread after so long, didn't have a Pi at
> hand. I have attached a very simple patch which reproduces the bug.
> You'll need to connect two I2C slave Teensy LC to the Pi. I have also
> attached the two Arduino files that should be loaded to the Teensies.
>
> What happens with this setup is that the Teensy that listens to 0x09
> (i2c_mess2.ino file) receives messages even when something is sent to
> 0x0A. The Teensy that listens to 0x0A (i2c_mess1.ino file) doesn't seem
> to be receiving anything.
>
> One Teensy prints to the serial console and the other responds by
> lighting up and turning off the LED on pin 13.
>
> On 12/9/20 11:02 μ.μ., Martin Peach wrote:
> > On Thu, Sep 10, 2020 at 2:25 PM Alexandros  wrote:
> >> When trying to send messages to two I2C slaves from the Pi with [pii2c]
> >> the following happens:
> >>
> >> If I send this message to [pii2c 0x0A]:
> >> "write 3 127 7"
> >>
> >> it arrives properly at the slave address 0x0A.
> >>
> >> If I change the address to 0x09 with the message "addr 0x09" and then
> >> send this message:
> >> "write 97"
> >>
> >> then both messages will be sent to the respective slaves, meaning that
> >> "3 127 7" will be sent to slave 0x0A and "97" to slave 0x09. If I then
> >> change the message sent to 0x09 to "98", this will be sent to 0x09, but
> >> again "3 127 7" will be sent to 0x0A. If I resend "3 127 7" to 0x0A,
> >> "98" (the last message set to 0x09) will be sent to 0x09 as well.
> >>
> >> The same behavior occurs when I send the message "write 0x09 98". The
> >> same behavior also occurs if I use two different [pii2c] objects, like 
> >> this:
> >>
> >> [write 3 127 7(
> >> |
> >> [pii2c 0x0A]
> >>
> >> [write 97(
> >> |
> >> [pii2c 0x09]
> >>
> >>
> > Hmmm I don't get this. Do you have a patch that will reproduce the bug?
> > (I am also able to send messages longer than 32 bytes, with
> > MAX_I2C_BUF_SIZE 64 in my copy of pii2c.c.)
> > I used a teeny 3.2 as a slave (using i2c_t3 from
> > https://github.com/nox771/i2c_t3) listening on all addresses. It only
> > receives the messages on the addresses I set in the Pd patch.
> >
> > Perhaps you have a hidden [pii2c 0x0A] somewhere that is also
> > receiving your write messages.
> > Since [pii2c] is using the same memory space for each message any new
> > message will effectively erase the old ones, so it's hard to explain
> > two different messages coming from a single object.
> >
> > Martin



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

Re: [PD] problem with correct numbers in pd double precision / problem with div and mod

[Martin Peach]

On Wed, Sep 23, 2020 at 11:19 AM hans w. koch  wrote:
>.
> but they only go until 2147483647
> anything special about this number?

https://en.wikipedia.org/wiki/2,147,483,647#In_computing



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

Re: [PD] [pii2c] keeps and resends previous messages when addresses change

[Martin Peach]

On Thu, Sep 10, 2020 at 2:25 PM Alexandros  wrote:
>
> When trying to send messages to two I2C slaves from the Pi with [pii2c]
> the following happens:
>
> If I send this message to [pii2c 0x0A]:
> "write 3 127 7"
>
> it arrives properly at the slave address 0x0A.
>
> If I change the address to 0x09 with the message "addr 0x09" and then
> send this message:
> "write 97"
>
> then both messages will be sent to the respective slaves, meaning that
> "3 127 7" will be sent to slave 0x0A and "97" to slave 0x09. If I then
> change the message sent to 0x09 to "98", this will be sent to 0x09, but
> again "3 127 7" will be sent to 0x0A. If I resend "3 127 7" to 0x0A,
> "98" (the last message set to 0x09) will be sent to 0x09 as well.
>
> The same behavior occurs when I send the message "write 0x09 98". The
> same behavior also occurs if I use two different [pii2c] objects, like this:
>
> [write 3 127 7(
> |
> [pii2c 0x0A]
>
> [write 97(
> |
> [pii2c 0x09]
>
>

Hmmm I don't get this. Do you have a patch that will reproduce the bug?
(I am also able to send messages longer than 32 bytes, with
MAX_I2C_BUF_SIZE 64 in my copy of pii2c.c.)
I used a teeny 3.2 as a slave (using i2c_t3 from
https://github.com/nox771/i2c_t3) listening on all addresses. It only
receives the messages on the addresses I set in the Pd patch.

Perhaps you have a hidden [pii2c 0x0A] somewhere that is also
receiving your write messages.
Since [pii2c] is using the same memory space for each message any new
message will effectively erase the old ones, so it's hard to explain
two different messages coming from a single object.

Martin



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

Re: [PD] [pii2c] won't send more than 32 bytes

[Martin Peach]

On Tue, Sep 1, 2020 at 1:19 PM Alexandros  wrote:
>
> The MAX_I2C_BUF_SIZE macro in pii2c.c is set to 64, but still when I try
> to send 64 bytes to a slave Teensy, only 32 go through, the rest 32 are
> all 0s. Raising this value to an even greater number, like 128 (which is
> something I would like to implement), gives similar results. The same
> behavior occurs whether I set the I2C address as an argument to the
> object, or if I pass it through the "write" message.
>
> I checked the code and couldn't find where this occurs. I added this:
>
> `post("%d", x->x_xferbuf[i-1]);`
>
> to line 348 to make sure the bytes are stored in the object's buffer,
> and they do get stored properly. The only place I found they end up in
> is a "write()" function, called in line 293, inside the pii2c_writer()
> function. I guess this function is from one of the header files included
> in the object, as I couldn't find it in the code.
>
> Long story short, is it possible to send more than 32 bytes over I2C in
> the Pi? I really like [pii2c], and since wiringPi is now deprecated, I'd
> like to stick to this object.
>

It seems to be an issue with the kernel driver. Whoever wrote it got
it into thieir head that there was a 32-byte limit. I found this
discussion:
https://stackoverflow.com/questions/25982525/why-i2c-smbus-block-max-is-limited-to-32-bytes
The same thing happens in Arduino, but there you can edit Wire.h to
get bigger messages.
I guess it will be fixed eventually.
Meanwhile, do you really need to use I2C? SPI is much faster and has
no limit to the message size. I also made a [pispi] external...
I find in general it's easier to plug an arduino into the pi to do
realtime stuff.

Martin



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



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

Re: [PD] Advice on creating an external object for controlling a DAC breakout board

[Martin Peach]

On Sun, Aug 16, 2020 at 5:29 AM Alexandros  wrote:
>
> Ok, I scanned through your code and your object doesn't depend on
> wiringPi, and it's actually a really nice object. By no means would I be
> able to write something as close to this!

Thanks Alexandros!

>
> I have one question though, in the help patch you write the following
> comment: "Only one I2C device is available on the Pi.". How come? Don't
> I2C devices all connect to one bus and listen only when they are
> addressed? Currently I don't have more than one I2C devices to check,
> but only one.

Sorry, I meant to say that on the Pi header there is only one
accessible I2C bus. You can have up to 127 devices on it.

Martin


>
> Thanks,
> Alexandros
>
> On 16/8/20 10:31 π.μ., Alexandros wrote:
> > Actually you're right, signal rate could be an overkill for something
> > like that. I'll go with control rate. Does your object use wiringPi? If
> > so, I'd go for creating a new object as wiringPi is now deprecated as
> > stated here http://wiringpi.com/news/ since the developer got bullied
> > about support and all. I'll try the pigpio software. Still, I'll give
> > your object a try and peek into the code, thanks!
> >
> > Anyway, thanks for the hints!
> >
> > Alexandros
> >
> > On 15/8/20 10:02 μ.μ., Martin Peach wrote:
> >> Hi Alexandros,
> >> I made an external  [pii2c] which should be available via deken along
> >> with the source code. You could use that to talk to the dacs, but not
> >> at signal rate. What you want is already done by any 4-channel USB
> >> audio interface for much less hassle, and better resolution with [dac~
> >> 1 2 3 4]. The 4-DAC board could be used to provide control voltages
> >> for an analog synth or something like that at control rate (once per
> >> 64-sample block).
> >>
> >> Martin
> >>
> >> On Sat, Aug 15, 2020 at 2:25 AM Alexandros  wrote:
> >>> I want to create an external object to control a quad DAC board with a 
> >>> Raspberry Pi, namely this one. As the object should run at signal rate, 
> >>> I'm confused as to how I should control the rate of values sent to the 
> >>> DAC.
> >>>
> >>> Since all signal objects in Pd work on DSP ticks, processing as many 
> >>> samples as the block size as fast as possible, how should I go about 
> >>> sending values to the DAC on a one-sample based clock? Is resampling the 
> >>> way to go? If so, how can this be done? I'm checking the source files, 
> >>> specifically d_dac.c and m_pd.h, but can't make much out of it. My C 
> >>> skills are very limited, hence all the questions above...
> >>>
> >>> ___
> >>> Pd-list@lists.iem.at mailing list
> >>> UNSUBSCRIBE and account-management -> 
> >>> https://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Advice on creating an external object for controlling a DAC breakout board

[Martin Peach]

Hi Alexandros,
I made an external  [pii2c] which should be available via deken along
with the source code. You could use that to talk to the dacs, but not
at signal rate. What you want is already done by any 4-channel USB
audio interface for much less hassle, and better resolution with [dac~
1 2 3 4]. The 4-DAC board could be used to provide control voltages
for an analog synth or something like that at control rate (once per
64-sample block).

Martin

On Sat, Aug 15, 2020 at 2:25 AM Alexandros  wrote:
>
> I want to create an external object to control a quad DAC board with a 
> Raspberry Pi, namely this one. As the object should run at signal rate, I'm 
> confused as to how I should control the rate of values sent to the DAC.
>
> Since all signal objects in Pd work on DSP ticks, processing as many samples 
> as the block size as fast as possible, how should I go about sending values 
> to the DAC on a one-sample based clock? Is resampling the way to go? If so, 
> how can this be done? I'm checking the source files, specifically d_dac.c and 
> m_pd.h, but can't make much out of it. My C skills are very limited, hence 
> all the questions above...
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] 0.51-1-test1 issues

[Martin Peach]

It looks as though you could change the whole palette to e.g. a dark
mode, without changing any other drawing code:
https://www.tcl.tk/man/tcl8.6/TkCmd/palette.htm

Martin

On Thu, Aug 13, 2020 at 3:36 PM Dan Wilcox  wrote:
>
>
> On Aug 13, 2020, at 8:04 PM, Alexandre Torres Porres  wrote:
>
>> I will add a bug fix PR which sets this automatically when you start the 
>> GUI, as with a couple of other settings which Pd needs by default. I 
>> honestly do not have the time to dig any further into this, ie. full dark 
>> mode support.
>
>
> there's also this oldest feature PR on github 
> https://github.com/pure-data/pure-data/pull/196 which opens the door to 
> setting user defined color schemes and plugins for it. I think it is ready to 
> go. With this one merged, I imagine it wouldn't  be hard to have a setting 
> inside Pd to change/switch modes, and we could have some hardcoded ones, such 
> as "regular", "dark", "Pd extended-like"
>
>
> I'm referring less to the canvas and more to the rest of the GUI. Most 
> widgets and windows have explicit colors set such as light gray, etc. If you 
> only implement canvas color schemes, the windows will still all be light.
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] Pd 0.50-2 on macos 11.0 BigSur beta

[Martin Peach]

The build farm used by Pd-extended worked very well for me. It would
be nice to have such a setup integrated with the deken system, so
anyone could upload their externals and they would be built and
packaged online instead of each developer needing to acquire one of
each machine on a 3-year rolling plan.

Martin


On Mon, Jul 6, 2020 at 1:28 PM Dan Wilcox  wrote:
>
> Yeah, VMs could be a good solution. I didn't mean my suggestion to sound 
> "anti-Miller" but more a response when I hear "I cannot code but I want to 
> help with Pd development." :)
>
> I have just 1 laptop and generally don't upgrade until a month or so after a 
> new OS release or at least when there is downtime between projects. This time 
> around, I am skipping macOS 10.15. This means I'm slow in testing new 
> versions, personally.
>
> I could probably buy a Mac mini as well and set up a testing / build system, 
> but I think my point is more toward pushing for a little more institutional 
> support for some of these common issues. I think Joe Deken's university 
> connections are also ready and willing for remote computing / hosting 
> capacity, if I recall correctly. It's a good idea to find ways to spread the 
> technical debt around.
>
> On Jul 6, 2020, at 6:47 PM, Miller Puckette  wrote:
>
> Just to respond to one item here...
>
>
> I have intimated this before, but perhaps I should now just say it:
>
> Can some institution which relies on using Pd with macOS simply buy Miller 
> and/or the Pd community a new Mac mini to support development efforts on the 
> platform for the next 10 years? This is not too much to ask, especially if 
> you lump it into the "year end" budget category.
>
>
> I can buy myself a macmini if it came to it.  But this gives me the idea that
> my own department should be running Mac VMs - there are three faculty and
> several grad students developing software here and having 2 or 3 versions
> of MacOS running on VMs might make our lives a lot easier.  I'm going to start
> by asking them to set up MacOS 11 :)
>
> M
>
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] tcpserver, flush?

[Martin Peach]

On Mon, Jun 15, 2020 at 3:09 PM Christof Ressi  wrote:
>
> > I have revised the code in those objects
> I see some bug fixes and the REUSEADDR and NODELAY options, that's cool!
>
> If you have lots of free time, you also might want to revise the whole
> threading code. Spawning a new thread for every list of bytes is not
> only excessively wasteful (especially in a soft-realtime environment),
> but also breaks determinism: if you send list A and list B in short
> succession, thread A is not guaranteed to call "send()" before thread B,
> so bytes might arrive out of order on the other side. Instead push the
> bytes to a ringbuffer (preferrably lockfree) and let a *single* sender
> thread consume it.
>

Yes, that's next. I first wanted to see if I have stopped the crashes
that seemed to be due to non-threadsafe calls. The one crash report
I've seen shows it occurring inside Pd's main event loop because of a
call to clockdelay from another thread while Pd is manipulating the
same clock. If it works, It's nearly ready to move to a single thread,
I already use a thread to receive and check for completed sends.
Should be ready by next week :)
.


Martin



> Christof
>
> On 15.06.2020 19:46, Martin Peach wrote:
> > On Mon, Jun 15, 2020 at 12:32 PM Christof Ressi  
> > wrote:
> >
> >> I've said this elsewhere: as much as I like (and use) the mrpeach library, 
> >> I avoid the net objects (especially [tcpclient] and [tcpserver]) because 
> >> there are too many problems in the code. [iemnet], on the other hand, has 
> >> been (re)written and maintained by actual domain experts.
> > I have revised the code in those objects and just uploaded the whole
> > mrpeach for Windows10 to deken. (this includes fixes to tcpserver and
> > tcpclient as well as midifile) So anyway I have lots of free time now
> > and I am maintaining the library, in the sourceforge svn repo
> > (https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/).
> > If there were a git repo for externals I would use that but it seems
> > scattered at the moment.
> >
> > Martin
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] tcpserver, flush?

[Martin Peach]

On Mon, Jun 15, 2020 at 12:32 PM Christof Ressi  wrote:

> I've said this elsewhere: as much as I like (and use) the mrpeach library, I 
> avoid the net objects (especially [tcpclient] and [tcpserver]) because there 
> are too many problems in the code. [iemnet], on the other hand, has been 
> (re)written and maintained by actual domain experts.

I have revised the code in those objects and just uploaded the whole
mrpeach for Windows10 to deken. (this includes fixes to tcpserver and
tcpclient as well as midifile) So anyway I have lots of free time now
and I am maintaining the library, in the sourceforge svn repo
(https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/).
If there were a git repo for externals I would use that but it seems
scattered at the moment.

Martin



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

Re: [PD] tcpserver, flush?

[Martin Peach]

On Mon, Jun 15, 2020 at 10:11 AM Christof Ressi  wrote:
>
> > Based on my assumptions, it may be that the OS is delaying sending the
> > messages in case you're not finished sending them.
> I think that's why Pd (and iemnet) sets the TCP_NODELAY socket option on
> TCP sockets .

Right! I have that on tcpreceive and tcpsend but didn't add it to the
tcpclient and tcpserver for some reason. I will fix that.

Martin


>
> Christof
>
> On 15.06.2020 15:44, Martin Peach wrote:
> > On Sun, Jun 14, 2020 at 4:24 PM  wrote:
> >> (Windows 10, Pd-50.0)
> >>
> >> i'm sending  messages of 25 bytes with [mrpeach/tcpserver] to a client 
> >> (NodeMCU/ESP8266),
> >>
> >> triggered by [metro 50].
> >>
> >> with a tcpclient in a seperate Pd the messages are received in the right 
> >> order, no gaps.
> > Are both Pds on the same machine? (I'm guessing yes)
> >
> >
> >> on the Node i get sometimes 1, most of the times multiple messages in one 
> >> read.
> >>
> > Are they multiples of the same message or a sequence? (I'm guessing a 
> > sequence)
> >
> >> the sending is done with "broadcast", because in the future there will be 
> >> more clients.
> >>
> > Does it also happen if you send only to that client? (I'm guessing yes)
> >
> >> how come the [mrpeach/tcpclient] and the WifiClient on the Node give 
> >> different results,
> >>
> >> and can tcpserver be 'forced' to treat them equally?
> >>
> > Based on my assumptions, it may be that the OS is delaying sending the
> > messages in case you're not finished sending them. You need a break of
> > some minimum time before the whole lot gets sent. The OS may delay
> > longer in the case of a wireless connection to avoid network
> > congestion. This is because TCP has no concept of packet or 'datagram'
> > like UDP -- you can keep sending until you close the connection, so
> > one way is to close the connection after each message. Another way
> > would be to use a longer metro tick period so the stack times out and
> > sends. Also try sending a longer message to force it to be sent.
> >
> > Martin
> >
> >
> >> any hint is welcome.
> >>
> >> rolf
> >>
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> https://lists.puredata.info/listinfo/pd-list
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list



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

Re: [PD] tcpserver, flush?

[Martin Peach]

On Sun, Jun 14, 2020 at 4:24 PM  wrote:
>
> (Windows 10, Pd-50.0)
>
> i'm sending  messages of 25 bytes with [mrpeach/tcpserver] to a client 
> (NodeMCU/ESP8266),
>
> triggered by [metro 50].
>
> with a tcpclient in a seperate Pd the messages are received in the right 
> order, no gaps.

Are both Pds on the same machine? (I'm guessing yes)


>
> on the Node i get sometimes 1, most of the times multiple messages in one 
> read.
>

Are they multiples of the same message or a sequence? (I'm guessing a sequence)

>
> the sending is done with "broadcast", because in the future there will be 
> more clients.
>

Does it also happen if you send only to that client? (I'm guessing yes)

>
> how come the [mrpeach/tcpclient] and the WifiClient on the Node give 
> different results,
>
> and can tcpserver be 'forced' to treat them equally?
>

Based on my assumptions, it may be that the OS is delaying sending the
messages in case you're not finished sending them. You need a break of
some minimum time before the whole lot gets sent. The OS may delay
longer in the case of a wireless connection to avoid network
congestion. This is because TCP has no concept of packet or 'datagram'
like UDP -- you can keep sending until you close the connection, so
one way is to close the connection after each message. Another way
would be to use a longer metro tick period so the stack times out and
sends. Also try sending a longer message to force it to be sent.

Martin


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



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

Re: [PD] udpsend: unsure about raw data

[Martin Peach]

On Sun, May 24, 2020 at 1:37 PM  wrote:
>
> how can my NodeMCU's become a client of the TCPserver?
>

Assuming you're programming it using the Arduino IDE, use the
functions in WiFiClient.h to connect to the server on whatever port
you want to use. Each client on [tcpserver] will have an ID that you
can use to route the traffic with.

Martin

> rolf
>
> Martin Peach schreef op 24-05-2020 19:10:
> > On Sun, May 24, 2020 at 12:09 PM  wrote:
> >>
> >> @martin
> >> there will be a minimum of 12 clients (NodeMCU's).
> >> hence, i thought about using multicast.
> >> the clients themself sort out which part of the message is for them.
> >>
> >> switching to TCP would mean a lot of connects and disconnects or
> >> as many [udpsend] objects as there are clients.
> >> am i right about this?
> >
> >
> > You could use [tcpserver], which can maintain multiple connections.
> >
> > Martin



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

Re: [PD] tcpclient-help hangs Pd-50 on my Windows 10

[Martin Peach]

On Sun, May 24, 2020 at 12:13 PM  wrote:
>
> hi,
>
> tcpclient-help hangs Pd-50 with the message:
>
> cannot find entry point for procedure atom_getblob in str.dll


That seems to be related to a [str] object in the help patch, not
related to [tcpclient].

>
> str-help gives the same.
>

Yes, [str] is obsolete, as it requires a patch to Pd that pd-extended
used to perform. I will remove it from the repo.


>
> which-help crashes Pd.
>

[which] depends on how it was compiled, if it uses the same c runtime
as Pd or not (an issue with Windows) . It seems to work on linux.

Martin.



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

Re: [PD] udpsend: unsure about raw data

[Martin Peach]

On Sun, May 24, 2020 at 10:09 AM  wrote:
>
> thanks Andy,
>
> in my case i'm sending to NodeMCU's (a breakoutboard with ESP8266 chip).
> so..

I have used it the other way, sending sensor data from an ESP8266 to a
Pd patch. Using UDP I was getting about 30% dropped packets, so I
switched to TCP and now I get less than 1% packet loss.
Since UDP is send and forget and WiFi is noisy, while TCP retries
until the packet gets through (mostly).
Since I have only one connection going, the threading stuff is irrelevant.

Martin



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

Re: [PD] udpsend: unsure about raw data

[Martin Peach]

On Sun, May 24, 2020 at 8:07 AM Christof Ressi  wrote:
> BTW, I strongly recommend using [iemnet] over [mrpeach]'s netobjects! The 
> former has a much better threading model and gets more frequent updates.


I find the mrpeach net objects work just fine for a simple setup. The
problems seem to arise when lots of connections are being made and
broken at high speed. The patches required to do this are apparently
so complex that noone has yet posted an example that will crash the
object(s), which makes it hard to debug.

Martin



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

Re: [PD] Add commas to an OSC-message

[Martin Peach]

On Thu, May 21, 2020 at 5:19 AM Patrick Heidegger via Pd-list
 wrote:
>
> Hello all,
>
> I want to send controls for multiple fx-parameters in Reaper with a single 
> OSC-message.
> Controls for multiple parameters in reaper are defined like:
>
> /track/1/fx/2/fxparm/x1,x2,x3,x4/value y1 y2 y3 y4
>
> where xn are the parameter index and yn are the assigned values.
> I know that commas in PD usually can not be used in this way.
>
> Is there any workaround?

If you want to send y1 to/track/1/fx/2/fxparm/x1 and y2 to
/track/1/fx/2/fxparm/x1x2 etc. , just make four separate messages like
/track/1/fx/2/fxparm/x1 y1
They could be in a bundle together.
If you want to send all the ys to each of the four endpoints then it
should be written* :
/track/1/fx/2/fxparm/{x1,x2,x3,x4} y1 y2 y3 y4
...which is problematic in Pd because of the way text input is
interpreted as TCL at some points, so again it's easier to make four
separate messages. In a bundle they will have a timestamp so they will
act simultaneously.


Martin

*http://opensoundcontrol.org/spec-1_0 "OSC Message Dispatching and
Pattern Matching"



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

Re: [PD] loading externals on Debian (was Re: Py/pyext not recognized...)

[Martin Peach]

On Mon, May 18, 2020 at 6:17 PM Christof Ressi  wrote:
>
> I get the same, and I don't yet understand why it doesn't show,
> although a midifile-help.pd file is there.
>
> It's because [midifile] sets "midifile-help" as the help symbol instead of 
> just "midifile", so Pd looks for "midifile-help-help.pd".
>
> https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/mrpeach/midifile/midifile.c

There are a few variations of the use of class_sethelpsymbol in
https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals.
Some of them use the '-help' extension, others also add '.pd', most
don't have any extension. If class_sethelpsymbol should only be used
if the help file is named something other than classname-help.pd,
I'll just remove that line. I see it's also used incorrectly in
udpsend~c.

Martin



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

Re: [PD] problem with connecting to Arduino

[Martin Peach]

On Fri, Apr 24, 2020 at 2:22 PM  wrote:
>
> Martin Peach schreef op 24-04-2020 19:44:
> > On Fri, Apr 24, 2020 at 1:34 PM  wrote:
> >>
> >> Martin Peach schreef op 24-04-2020 18:51:
> >> > On Fri, Apr 24, 2020 at 10:40 AM  wrote:
> >> >>
> >> >> i've been working with the Arduino UNO and Pd for years.
> >> >> now i'm starting with a new board UNO Wifi Rev2.
> > ...
> >> (with the regular UNO this behavior doesn't happen)
> >> i'm not sending anything at startup.
> >> this is what [info) gives:
> >>
> >> print: open 1
> >> print: port 5
> >> print: baud 9600
> >> print: dsr 0
> >> print: cts 0
> >> print: parity 0
> >> print: stop 1
> >> print: data 8
> >> print: rtscts 0
> >> print: xonxoff 0
> >> print: hupcl 1
> >> print: rxerrors 0
> >>
> >
> > Here I  get the same thing with a functional device except I have cts
> > 1. Do you get that with the UNO?
> > You could try sending [dtr 1(  or [rtscts1( and [rts 1( to see if it
> > wants some hanshaking.
> >
> > Martin
>
> wow, [dtr 1( did the trick!
> what does it mean?

Old-style RS-232 ports had handshaking lines in pairs RTS/CTS
(ready-to-send/ clear-to-send) and DTR/DSR (data-terminal-ready/
data-set-ready) that were used to control the modem data flow. It
seems that some USB drivers also use these signals even though they
are not implemented as physical circuits.

> can i do this also when there's no problem like with the regular UNO?

It should be harmless.

Martin



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

Re: [PD] problem with connecting to Arduino

[Martin Peach]

On Fri, Apr 24, 2020 at 1:34 PM  wrote:
>
> Martin Peach schreef op 24-04-2020 18:51:
> > On Fri, Apr 24, 2020 at 10:40 AM  wrote:
> >>
> >> i've been working with the Arduino UNO and Pd for years.
> >> now i'm starting with a new board UNO Wifi Rev2.
...
> (with the regular UNO this behavior doesn't happen)
> i'm not sending anything at startup.
> this is what [info) gives:
>
> print: open 1
> print: port 5
> print: baud 9600
> print: dsr 0
> print: cts 0
> print: parity 0
> print: stop 1
> print: data 8
> print: rtscts 0
> print: xonxoff 0
> print: hupcl 1
> print: rxerrors 0
>

Here I  get the same thing with a functional device except I have cts
1. Do you get that with the UNO?
You could try sending [dtr 1(  or [rtscts1( and [rts 1( to see if it
wants some hanshaking.

Martin



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

Re: [PD] problem with connecting to Arduino

[Martin Peach]

On Fri, Apr 24, 2020 at 10:40 AM  wrote:
>
> i've been working with the Arduino UNO and Pd for years.
> now i'm starting with a new board UNO Wifi Rev2.
>
> the board works with the Arduino IDE, also with the IDE's serial monitor.
>
> the problem with Pd is in the initialization.
>
> when the board is powered on and i open the port in Pd, nothing happens. no 
> 'hello world' or whatever comes through, no lights on the board show any 
> activity.
>
> [comport] doesn't give any error message.
>
> when i close the port in Pd, go to the IDE, start the serial monitor, the 
> board comes alive, spits out the text.
> closing the IDE, opening the port in Pd again, dadada, the text shows up.
> as long as the board stays plugged in, the communication gives no problems.
>
> in Windows 10 the port for a 'regular' UNO appears as "Arduino UNO (COM5)".
> the new board as "mEDBG Virtual COM Port (COM4)".
>
> is it possible that [comport] fails to initialize this particular type?
>

It's the OS that operates the port, so that's not the problem since it
works OK in the IDE. Maybe you are sending something to the arduino
right at startup? This causes the arduino to appear to freeze, as it's
triggered the bootloader which is now waiting for you to upload a
program to it.
Also, you can send the [info( message to [comport] to get a status
report via its right outlet.


Martin



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

[PD] Number Boxes, Sliders, Symbols - strange behavior (no graphic update)

[Martin Peach]

Hi,
Ingo reported that "
For those who are interested what the issue was:
I was moving a window with [hcs/sysgui] automatically during startup.
When the window is visible everything is ok.
When the window is hidden with [*** vis 0( most graphical objects mentioned
above stop updating their graphics.
I. e. a slider sends the values but the slider stays graphically at the
default setting that it had during creation.
Now I'm moving windows with [hcs/sysgui] only when they are visible and it
works again."

Now I'm on Windows10 running pd 0.50.1, not using [hcs/sysgui]. I use
the zoom feature since I would need a microscope to view the patch
(well not quite -- the letter 'F' in 'File' on the menu of the main Pd
window is 1.38mm high).
Anyway, the graphics freeze, in that bot types of number boxes,
arrays, radio buttons, etc.  don't update on the screen although they
remain functional otherwise.
Buttons still flash when banged via the patch or by clicking, but not
much else works. This seems to happen after the screen blanks but I'm
not sure if that's the cause since it takes a while before it happens.

Martin



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

Re: [PD] including bpm info to midi-recording

[Martin Peach]

On Mon, Apr 6, 2020 at 3:27 AM Jakob Laue  wrote:
>
> Hey Martin,
> thanks for your hints!
>
> I created a midi file in ableton, exported it and then read it with the 
> midifile-read-help-patch.
> This is what I get after reading:
>
> midifile: opened /Users/wbjc/Desktop/ableton.mid
> midifile: Header chunk type: MThd
> midifile: Header chunk length: 6
> midifile: Header chunk format: 0 (Single multichannel track)
> midifile: Header chunk ntrks: 1
> midifile: Header chunk division: 0x60: 96 ticks per quarter note
> midifile: Track chunk 0 type: MTrk, length 81
>
>
>
> And this is what I get after the |dump 0( message:
>
>
>
>
> midifile: Parsing track[0]...
> midifile: tick 0 delta 0 status FF Meta 0x03 length 1
> Sequence/Track Name
> midifile: tick 0 delta 0 status FF Meta 0x58 length 4
> Time Signature 4/4 36 clocks per tick, 8 32nd notes per quarter note
> midifile: tick 0 delta 0 status FF Meta 0x58 length 4
> Time Signature 4/4 36 clocks per tick, 8 32nd notes per quarter note
> midifile: tick 0 delta 0 status 90 MIDI 0x90 42 64 : channel 1 Note 66 On 
> velocity 100
> midifile: tick 24 delta 24 status 80 MIDI 0x80 42 40 : channel 1 Note 66 Off 
> velocity 64
> midifile: tick 72 delta 48 status 90 MIDI 0x90 41 64 : channel 1 Note 65 On 
> velocity 100
> midifile: tick 96 delta 24 status 80 MIDI 0x80 41 40 : channel 1 Note 65 Off 
> velocity 64
> midifile: tick 120 delta 24 status 90 MIDI 0x90 46 64 : channel 1 Note 70 On 
> velocity 100
> midifile: tick 144 delta 24 status 80 MIDI 0x80 46 40 : channel 1 Note 70 Off 
> velocity 64
> midifile: tick 168 delta 24 status 90 MIDI 0x90 41 64 : channel 1 Note 65 On 
> velocity 100
> midifile: tick 192 delta 24 status 80 MIDI 0x80 41 40 : channel 1 Note 65 Off 
> velocity 64
> midifile: tick 216 delta 24 status 90 MIDI 0x90 40 64 : channel 1 Note 64 On 
> velocity 100
> midifile: tick 240 delta 24 status 80 MIDI 0x80 40 40 : channel 1 Note 64 Off 
> velocity 64
> midifile: tick 264 delta 24 status 90 MIDI 0x90 45 64 : channel 1 Note 69 On 
> velocity 100
> midifile: tick 288 delta 24 status 80 MIDI 0x80 45 40 : channel 1 Note 69 Off 
> velocity 64
> midifile: tick 312 delta 24 status 90 MIDI 0x90 41 64 : channel 1 Note 65 On 
> velocity 100
> midifile: tick 336 delta 24 status 80 MIDI 0x80 41 40 : channel 1 Note 65 Off 
> velocity 64
> midifile: tick 336 delta 0 status FF Meta 0x2F length 0
> End of Track 0==
>
>
>
> The differences that I noticed:
>
> In the ableton-file the "header chunk division" is given as "ticks per 
> quarter note", whereas in the midifile-file it is given in "frames per second 
> and ticks per frame".
>
>
>
> midifile: Header chunk division: "0x60: 96 ticks per quarter note"
> midifile: Header chunk division: "0xE714: 25 frames per second, 20 ticks per 
> frame"
>
>
> In the ableton-file there is an info given about the time signature: "Time 
> Signature 4/4 36 clocks per tick, 8 32nd notes per quarter note"
>
> This info is not present after loading the file that i recorded with 
> [midifile].

You have to add it yourself, since [midifile] has no idea what time
signature or tempo you are using (when writing, the ticks don't have
to be in real time).
With the latest version of [midifile] there is a [meta( message for
this. With earlier versions you can write the meta tags directly, for
example to get the time signature,
Time Signature 4/4 36 clocks per tick, 8 32nd notes per quarter note
you can send
[255 88 4 4 36 8{
and the tempo
[255 81 50(
sets 50 microseconds per quarter note.

You can find more info here:
http://www.music.mcgill.ca/~ich/classes/mumt306/StandardMIDIfileformat.html

Martin
> 
>
>
> Furthermore, looking at the first lines of the dump-info of the 
> ableton-exported-file, we can see that there is also one note being played at 
> tick 0, but I did not actually put a note there. The same applies for the 
> [midifile]-recorded file. I did not play notes directly after hitting the 
> record-[bang]. I don't know how these notes on the first tick (0) have gotten 
> there.
>
> As a side-note the help-patches that I am using are from 2010 
> (write-help-patch) and 2011 (read-help-patch). These were included in the 
> mrpeach_v0-0-extended package that I downloaded via deken.
>
> Best, Jakob



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

Re: [PD] including bpm info to midi-recording

[Martin Peach]

On Sun, Apr 5, 2020 at 9:48 AM Jakob Laue  wrote:
>
> Hey Martin,
> I tried again today. I recorded a new midi file and then loaded it with the 
> midifile-read-help-patch.
>
> After loading the file I get:
>
> midifile: opened /Users/wbjc/Desktop/mpxy.mid
> midifile: Header chunk type: MThd
> midifile: Header chunk length: 6
> midifile: Header chunk format: 0 (Single multichannel track)
> midifile: Header chunk ntrks: 1
> midifile: Header chunk division: 0xE714: 25 frames per second, 20 ticks per 
> frame
> other_meta: frames_per_sec 25
> other_meta: ticks_per_frame 20
> midifile: Track chunk 0 type: MTrk, length 432
>
>
> And then if I send a |dump 0( message to [midifile] I get:
>
> midifile: Parsing track[0]...
> midifile: tick 0 delta 0 status 99 MIDI 0x99 24 60 : channel 10 Note 36 On 
> velocity 96
> midifile: tick 0 delta 0 status 89 MIDI 0x89 24 00 : channel 10 Note 36 Off 
> velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 2B 65 : channel 10 Note 43 On 
> velocity 101
> midifile: tick 0 delta 0 status 89 MIDI 0x89 2B 00 : channel 10 Note 43 Off 
> velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 2B 7F : channel 10 Note 43 On 
> velocity 127
> midifile: tick 0 delta 0 status 89 MIDI 0x89 2B 00 : channel 10 Note 43 Off 
> velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 25 72 : channel 10 Note 37 On 
> velocity 114
> midifile: tick 0 delta 0 status 89 MIDI 0x89 25 00 : channel 10 Note 37 Off 
> velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 25 72 : channel 10 Note 37 On 
> velocity 114
> midifile: tick 0 delta 0 status 89 MIDI 0x89 25 00 : channel 10 Note 37 Off 
> velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 24 7C : channel 10 Note 36 On 
> velocity 124
> midifile: tick 0 delta 0 status 89 MIDI 0x89 24 00 : channel 10 Note 36 Off 
> velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 26 67 : channel 10 Note 38 On 
> velocity 103
> midifile: tick 0 delta 0 status 89 MIDI 0x89 26 00 : channel 10 Note 38 Off 
> velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 26 6A : channel 10 Note 38 On 
> velocity 106
> midifile: tick 0 delta 0 status 89 MIDI 0x89 26 00 : channel 10 Note 38 Off 
> velocity 0
> midifile: tick 1052 delta 1052 status 99 MIDI 0x99 24 59 : channel 10 Note 36 
> On velocity 89
> midifile: tick 1073 delta 21 status 89 MIDI 0x89 24 00 : channel 10 Note 36 
> Off velocity 0
> midifile: tick 1120 delta 47 status 99 MIDI 0x99 24 6E : channel 10 Note 36 
> On velocity 110
> midifile: tick 1169 delta 49 status 89 MIDI 0x89 24 00 : channel 10 Note 36 
> Off velocity 0
> midifile: tick 1248 delta 79 status 99 MIDI 0x99 24 7F : channel 10 Note 36 
> On velocity 127
> midifile: tick 1287 delta 39 status 89 MIDI 0x89 24 00 : channel 10 Note 36 
> Off velocity 0
> midifile: tick 1400 delta 113 status 99 MIDI 0x99 24 6A : channel 10 Note 36 
> On velocity 106
> midifile: tick 1418 delta 18 status 89 MIDI 0x89 24 00 : channel 10 Note 36 
> Off velocity 0
> midifile: tick 1455 delta 37 status 99 MIDI 0x99 24 64 : channel 10 Note 36 
> On velocity 100
> midifile: tick 1502 delta 47 status 89 MIDI 0x89 24 00 : channel 10 Note 36 
> Off velocity 0
> midifile: tick 1591 delta 89 status 99 MIDI 0x99 2B 71 : channel 10 Note 43 
> On velocity 113
> midifile: tick 1657 delta 66 status 89 MIDI 0x89 2B 00 : channel 10 Note 43 
> Off velocity 0
> midifile: tick 1780 delta 123 status 99 MIDI 0x99 2B 7C : channel 10 Note 43 
> On velocity 124
> midifile: tick 1788 delta 8 status 99 MIDI 0x99 2A 29 : channel 10 Note 42 On 
> velocity 41
> midifile: tick 1854 delta 66 status 89 MIDI 0x89 2B 00 : channel 10 Note 43 
> Off velocity 0
> midifile: tick 1971 delta 117 status 99 MIDI 0x99 2B 7F : channel 10 Note 43 
> On velocity 127
> midifile: tick 2047 delta 76 status 89 MIDI 0x89 2B 00 : channel 10 Note 43 
> Off velocity 0
> midifile: tick 2213 delta 166 status 99 MIDI 0x99 25 6B : channel 10 Note 37 
> On velocity 107
> midifile: tick 2266 delta 53 status 89 MIDI 0x89 25 00 : channel 10 Note 37 
> Off velocity 0
> midifile: tick 2352 delta 86 status 99 MIDI 0x99 25 7C : channel 10 Note 37 
> On velocity 124
> midifile: tick 2366 delta 14 status 89 MIDI 0x89 25 00 : channel 10 Note 37 
> Off velocity 0
> midifile: tick 2424 delta 58 status 99 MIDI 0x99 25 73 : channel 10 Note 37 
> On velocity 115
> midifile: tick 2464 delta 40 status 89 MIDI 0x89 25 00 : channel 10 Note 37 
> Off velocity 0
> midifile: tick 2571 delta 107 status 99 MIDI 0x99 26 7B : channel 10 Note 38 
> On velocity 123
> midifile: tick 2634 delta 63 status 89 MIDI 0x89 26 00 : channel 10 Note 38 
> Off velocity 0
> midifile: tick 2726 delta 92 status 89 MIDI 0x89 2A 00 : channel 10 Note 42 
> Off velocity 0
> midifile: tick 2728 delta 2 status 99 MIDI 0x99 26 7F : channel 10 Note 38 On 
> velocity 127
> midifile: tick 2736 delta 8 status 99 MIDI 0x99 2A 24 : channel 10 Note 42 On 
> velocity 36
> midifile: tick 2794 delta 58 status 89 MIDI 0x89 26 00 : channel 10 Note 38 
> Off 

Re: [PD] including bpm info to midi-recording

[Martin Peach]

On Sat, Apr 4, 2020 at 4:57 PM Jakob Laue  wrote:
>
> Hey Martin,
> thanks for the hint. When I read a recorded file that should actually have 
> some recorded notes in it and then load it again with the 
> midifile-read-help-patch, then I get this (verbosity = 3)
>
> midifile_open_path (absolute): /Users/wbjc/Desktop/mp2.mid
>
> midifile: opened /Users/wbjc/Desktop/mp2.mid
> midifile: Header chunk type: MThd
> midifile: Header chunk length: 6
> midifile: Header chunk format: 0 (Single multichannel track)
> midifile: Header chunk ntrks: 1
> midifile: Header chunk division: 0xE714: 25 frames per second, 20 ticks per 
> frame
> other_meta: frames_per_sec 25
> other_meta: ticks_per_frame 20
> midifile: Track chunk 0 type: MTrk, length 35
>
>
> Does not look like something has been recorded, right?

The last line shows the track chink is 35 bytes long. Did you play it
to the end? The third outlet of [midifile] emits a bang when it gets
to the end.
If you waited a while after starting to record there may be a long
pause before something happens.
The [dump 0( message should output the entire track to the Pd window.

Martin



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

Re: [PD] including bpm info to midi-recording

[Martin Peach]

On Fri, Apr 3, 2020 at 4:41 PM Jakob Laue  wrote:
...
> Then I opened the help file directly from the ../Pd/externals/mrpeach-folder 
> by double-clicking it and I followed the steps for writing to a file. I
> - choose a file
> - put the 2 ms into the right inlet of [metro] and then start [metro]
> - hit some notes on a usb midi controller connected to pd (the [notein] shows 
> notes coming in)
> - hit |flush(
> - stop the metro
>
> Then I copy the newly created midi file into ableton, but I cannot see any 
> midi notes being displayed for that file.
>

Maybe try to load it using the midifile playback subpatch, You can set
the verbosity to see what was recorded, if  anything.
possibly ableton expects some meta information at the start of the file.

Martin



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

Re: [PD] including bpm info to midi-recording

[Martin Peach]

Hi Jakob,

I have uploaded Windows versions of midifile via deken -- look for
'midifile'. Unfortunately I have no access to a mac these days.
Someone else may be able to build it for mac, the source is included
in the package.

Martin

On Fri, Apr 3, 2020 at 2:30 PM Jakob  wrote:
>
> Hey Martin,
> Thanks for your message.
> I looked for mrpeach in deken, but the only result I get is mrpeach for 
> extended ( i am on mac os). Does that mean that I cannot use it?
>
> Best, Jakob
>
> > Am 03.04.2020 um 19:29 schrieb Martin Peach :
> >
> >> On Fri, Apr 3, 2020 at 12:39 PM Jakob Laue  wrote:
> >>
> >> hey,
> >> yes i think so because it seems that [seq] does not offer to specify some 
> >> kind of ticks when writing to a file.
> >> hmm.
> >>
> >
> > Have you tried [midifile] from mrpeach? It can write most of the tags.
> >
> > Martin
>



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

Re: [PD] including bpm info to midi-recording

[Martin Peach]

On Fri, Apr 3, 2020 at 12:39 PM Jakob Laue  wrote:
>
> hey,
> yes i think so because it seems that [seq] does not offer to specify some 
> kind of ticks when writing to a file.
> hmm.
>

Have you tried [midifile] from mrpeach? It can write most of the tags.

Martin



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

Re: [PD] tcpserver and tcpclient

[Martin Peach]

On Mon, Mar 30, 2020 at 3:36 AM Edwin van der Heide  wrote:
>
> It seems that objects from the mrpeach library give me trouble (crashing) 
> (especially on windows) although this needs further testing on my side.

Which mrpeach objects are crashing on Windows? I'd like to know so I can fix it.

Martin



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

Re: [PD] compiling hidio for Windows

[Martin Peach]

On Sun, Feb 2, 2020 at 1:46 PM ffdd cchh  wrote:
>
> Ok, I did Christof's step c) and copied those dummy functions (and basically 
> commented out anything but a debug_post() inside "hidio_devices()" and 
> "hidio_elements()", and indeed got a binary. But, it's no use.
>
> I try to get some data on why it crashes but it just says 'segmentation 
> fault':
>
> ```
> camarahalac.1@ACD-NC054624 MINGW64 ~/Desktop
> $ /c/Users/camarahalac.1/Downloads/pd-0.50-2/bin/pd.exe -d 4 -stderr -open 
> /c/Users/camarahalac.1/Downloads/pd-0.50-2/extra/hidio/hidio-help.pd
> Segmentation fault
> ```
>
I tried this using Msys64 but get
hidio_windows.c:37:10: fatal error: ddk/hidsdi.h: No such file or directory
   37 | #include 
I can't find any package for mingw64 that has this file. There is a
hidapi, which uses hidapi.h..
https://github.com/libusb/hidapi
It uses functions like
hid_get_manufacturer_string
instead of
HidD_GetManufacturerString
so it could probably be used fir the windows build.


Martin



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

Re: [PD] compiling hidio for Windows

[Martin Peach]

I'm not sure but I think -lhdi should be -lhid, since it's a human
interface device library.
See
https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts

Martin

On Sun, Feb 2, 2020 at 12:04 PM ffdd cchh  wrote:

> Hi Martin, Christof,
>
> thanks both. Still no luck.
>
> I managed through steps a) b) and d), with the exception that I could not
> add "-lhdi", as it appears to not be installed here. Is that pointing to
> this: https://cran.r-project.org/web/packages/hdi/index.html ?
>
> The log now points to *many* undefined references on mostly
> hidio_windows.c and on hidio.c (which I suspect is my missing step c), for
> which I did not have time)
>
> I attach the log here again.
>
> I have hit a brick wall here so I will not pursue this further unless
> there are other instructions I can follow.
>
> Thanks for you help,
>
> Best,
>
> fd
>
> On Fri, Jan 31, 2020 at 10:52 PM Christof Ressi 
> wrote:
>
>> The order of .o files doesn't matter. It's shared and static libraries
>> which sometimes have to be specified in a certain order.
>>
>> The actual problem was that
>>
>> a) hidio_windows.c used _WINDOWS instead of _WIN32 as a guard around the
>> whole code, so hidio_windows.o was empty.
>>
>> b) then there was a wrong header (  instead of )
>>
>> c) some methods are not implemented, so I copied the dummy implementation
>> from hidio_linux.c. It seems like those methods are only relevant for OSX.
>>
>> d) there were missing linker flags "-lhdi -lSetupAPI".
>>
>> Also, I couldn't get the autotools makefile to work, so I just compiled
>> manually on the command line. Finally I got a binary :-)
>>
>> To be honest, I don't think that anyone ever compiled this code on
>> Windows, so it is probably untested. Anyway, when I have time I can clean
>> this up and make a PR (or just fork it). Then we probably need some testing
>> before we upload it to Deken...
>>
>> Christof
>> On 01.02.2020 02:50, Martin Peach wrote:
>>
>> Line 76 of the log:
>> gcc  -DPD -g -O2 -I/z/Desktop/pure-data/src   -mms-bitfields
>>  -L/z/Desktop/pure-data/src -L/z/Desktop/pure-data/bin
>> -L/z/Desktop/pure-data/obj   -s -shared -o hidio.dll hidio.o hidio_types.o
>>   hidio_windows.o  -L/src -L/bin -L/obj -lpd
>> hidio.o: In function `hidio_tick':
>> Z:\Desktop\hidio/hidio.c:513: undefined reference to `hidio_get_events'
>>
>> hidio_tick is in hidio.o, which has compiled successfully.
>> hidio_get_events is in hidio_windows.o, which also exists; but the linker
>> is linking three .o files, and hidio_windows.o is the last one.
>> Perhaps switching hidio.o and hidio_windows.o in that gcc command will
>> let the linker find the symbols before they are needed.
>>
>> Martin
>>
>>
>>
>> On Fri, Jan 31, 2020 at 5:29 PM ffdd cchh  wrote:
>>
>>> Hi Christof,
>>>
>>> Thanks! Yes, I found these threads on the list:
>>>
>>> https://lists.puredata.info/pipermail/pd-list/2019-11/126348.html
>>> https://lists.puredata.info/pipermail/pd-list/2019-10/126096.html
>>>
>>> But, there are still no Windows version of this external...
>>>
>>> Github issue is up: https://github.com/Benitoite/hidio/issues/2
>>>
>>> Hope something comes out of this thread! I am sure there are enough
>>> Windows users out there in need of some hid external.
>>>
>>> Best,
>>>
>>> f
>>>
>>>
>>> On Fri, Jan 31, 2020 at 4:57 PM Christof Ressi 
>>> wrote:
>>>
>>>> I remember a similar thread on the list a few months ago. I tried to
>>>> compile it and gave up. The build system for Windows seems to be broken and
>>>> needs to be fixed (and probably switched from automake to pd-lib-builder).
>>>> Unfortunately, I don't have time right now to work on this, but you could
>>>> file a bug report on the GitHub repo, so maybe the maintainer will do it.
>>>>
>>>> Christof
>>>> On 31.01.2020 21:05, ffdd cchh wrote:
>>>>
>>>> Dear list,
>>>>
>>>> I need to use external controllers via USB with vanilla (say, a PS4
>>>> controller), and I have not found a compiled version of [hidio] for
>>>> Windows. Please, let me know if there are ready-made options out there
>>>> (feel free to change subject line if that thread goes wild).
>>>>
>>>> In the meantime, I am trying to compile [hidio] f

Re: [PD] compiling hidio for Windows

[Martin Peach]

Line 76 of the log:
gcc  -DPD -g -O2 -I/z/Desktop/pure-data/src   -mms-bitfields
 -L/z/Desktop/pure-data/src -L/z/Desktop/pure-data/bin
-L/z/Desktop/pure-data/obj   -s -shared -o hidio.dll hidio.o hidio_types.o
  hidio_windows.o  -L/src -L/bin -L/obj -lpd
hidio.o: In function `hidio_tick':
Z:\Desktop\hidio/hidio.c:513: undefined reference to `hidio_get_events'

hidio_tick is in hidio.o, which has compiled successfully.
hidio_get_events is in hidio_windows.o, which also exists; but the linker
is linking three .o files, and hidio_windows.o is the last one.
Perhaps switching hidio.o and hidio_windows.o in that gcc command will let
the linker find the symbols before they are needed.

Martin



On Fri, Jan 31, 2020 at 5:29 PM ffdd cchh  wrote:

> Hi Christof,
>
> Thanks! Yes, I found these threads on the list:
>
> https://lists.puredata.info/pipermail/pd-list/2019-11/126348.html
> https://lists.puredata.info/pipermail/pd-list/2019-10/126096.html
>
> But, there are still no Windows version of this external...
>
> Github issue is up: https://github.com/Benitoite/hidio/issues/2
>
> Hope something comes out of this thread! I am sure there are enough
> Windows users out there in need of some hid external.
>
> Best,
>
> f
>
>
> On Fri, Jan 31, 2020 at 4:57 PM Christof Ressi 
> wrote:
>
>> I remember a similar thread on the list a few months ago. I tried to
>> compile it and gave up. The build system for Windows seems to be broken and
>> needs to be fixed (and probably switched from automake to pd-lib-builder).
>> Unfortunately, I don't have time right now to work on this, but you could
>> file a bug report on the GitHub repo, so maybe the maintainer will do it.
>>
>> Christof
>> On 31.01.2020 21:05, ffdd cchh wrote:
>>
>> Dear list,
>>
>> I need to use external controllers via USB with vanilla (say, a PS4
>> controller), and I have not found a compiled version of [hidio] for
>> Windows. Please, let me know if there are ready-made options out there
>> (feel free to change subject line if that thread goes wild).
>>
>> In the meantime, I am trying to compile [hidio] for Windows. I'm on
>> Windows 10.0.18362, x64-based PC. I am using a MSYS terminal with MINGw64.
>> I took the latest code from Benitoite's repository (
>> https://github.com/Benitoite/hidio) and I am stuck with "undefined
>> reference"s all over. I attach here the console log.
>>
>> I would very much welcome any idea on how to approach this so I can use
>> vanilla with my students :)
>>
>> Best,
>>
>> f
>>
>>
>> ___pd-l...@lists.iem.at mailing 
>> list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
>>
>
>
> --
> fdch.github.io
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Raspberry Pi: Loading Samples RAM problem

[Martin Peach]

On Mon, Nov 11, 2019 at 1:56 PM Jakob Laue  wrote:

>
>
> Also, I don't have to adjust Pd's audio settings. I can use the standard
> settings (44100, 64 blocksize, 25 msec) and I don't get audio pops, which
> is good.
>
> But there is one thing that I realised: The wav-files are not played at
> original speed. They are all recorded in 122 bpm. When I play them with
> Giulois patch, the samples are played quite slowly, at around 111 bpm.
>

If the wav files were recorded at 48000 and played back at 44100 you would
get that.
(122/111 ~= 48000/44100)
Martin
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling externals for Pure Data windows

[Martin Peach]

I think it would be great if the compilation howto was appended to the
externals howto.

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

Re: [PD] stability of PD on Windows?

[Martin Peach]

On Fri, Sep 27, 2019 at 12:24 PM Christof Ressi 
wrote:

> > For me the audio is distorted unless I also tick "Use Callbacks".
>
> Really, even if you use an ASIO driver? I never had the experience that
> "Use Callbacks" improves things, on the contrary. Also, it's worth noting
> that with "Use Callbacks", the "delay" parameter doesn't do any thing, the
> latency can only be set with the ASIO block size.
>

I don't know which ASIO driver I'm using, maybe it came with the interface
(I selected "ASIO:Focusrite USB 2.0 Audio Driver" in the dialog). I tried
various delays with no callbacks and now I get no distortion with a delay
of 11 or more and block size 64. With Delay less than 11 the audio is
chopped up.
Without callbacks, I get clicks and dropouts occasionally if I do things
with the mouse. That's why I assumed it was the better choice. (Doesn't
audio processing always use callbacks anyway? Otherwise the program must
sit in a loop serving samples. What callbacks are these?)

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

Re: [PD] best non linear envelope design?

[Martin Peach]

On Sat, Jul 13, 2019 at 7:59 PM Alexandre Torres Porres 
wrote:

> yeah, both creb/eadsr~ and bsaylor/aenv~ seem to use a one pole filter
> design, even though both generate slightly different shapes.
>
>

Also mrpeach/rc~ does that. And banging the same value into a [line~]
faster than it ramps will give a piecewise-linear approximation. The 555
timer chip uses the middle third of the curve, which is more nearly linear.
Martin
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] control projector via LAN from PureData

[Martin Peach]

On Sat, Jun 15, 2019 at 1:14 PM Csaba Láng  wrote:

> Dear List,
>
> did anyone on this list try to control a projector via LAN?
> I guess comport works only for COM1 controller.
>
It should work with any serial device your OS knows about. You can specify
it by name or use the [devices{ message to get a list of what's available
on your machine. (And dont't forget to set the correct baud rate)

I plan to use RJ-45, but not sure if the comport external can handle it.
>
Do you mean RS485 hardware or RJ45 connector? RS485 should work the same as
an ordinary serial port, except for the bus direction signal, which has to
come from somewhere.

E.g. a message [02h00h00h00h00h02h( could turn on a
> projector, in my case it is NEC.
>
You would just send [2 0 0 0 0 2{ in that case, since Pd doesn't interpret
hexadecimal notation.

Martin

Any hints are welcome.
>
> Best,
>
> Popesz
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] https get in Pd

[Martin Peach]

On Wed, May 22, 2019 at 11:27 AM Roman Haefeli  wrote:

> On Wed, 2019-05-22 at 10:22 -0400, Martin Peach wrote:
> > I was looking into making a [httpsget]  external but the whole TLS
> > thing seems very difficult.
> > For my purposes on linux I use [shell] with wget to save the data to
> > a file, then open it with [binfile].
> > I was wondering if there is some cross-platform library to do the ssh
>
> I guess you mean SSL/TLS
>
>
Yes.

> , as I'm sure implementing it from scratch would take forever and be
> > very error-prone. Not to mention doing it using vanilla objects
>
> I don't see why someone would have to do the work, it's already done:
>
> ♥♥♥ purest_json ♥♥♥
>
> It does proper TLS and is cross-platform. Deken has binaries for
> Windows-i386 and they work, I just tested it (on Wine).
>
>
...but deken does not have it for 64bit Windows it seems. I never seem to
have the right installation ;(
Looking at the git (
https://github.com/residuum/PuRestJson/blob/master/Makefile)
there sem to be a lot of libraries involved. The makefile has:

define forWindows
ldlibs += -lpthread -lm -lwldap32 -lgnutls -lhogweed -lgmp -lssl -lnettle \
-lssh2 -lgcrypt -lgpg-error -lcrypto -lws2_32 -lgdi32 -lcrypt32 \
-lz -lunistring -lidn -lintl -liconv

It does look easier to just use Python for that stuff and let Pd do what
it's good at.

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

Re: [PD] https get in Pd

[Martin Peach]

On Wed, May 22, 2019 at 10:03 AM oliver  wrote:

>
> >>
> >> WINDOWS: [system] (in the "motex" library)
> >> LINUX & OSX: [shell] (in the "ggee" library)
>
> >
> > Yes, you can, but it is not portable (as it requires different
> > solutions depending on platform) and requires additional filesystem
> > interactions. Using [shell] (or [system] for that matter) has all kinds
> > of side effects, like [shell] searches scripts relative to Pd start
> > location instead of relative to Pd patch. I wouldn't recommend using
> > those
>
> you are right, it's more like a workaround/hack in case nothing else
> works. and it involves some tweaking, that's true.
>
> for the purpose of http-downloading, one would also need a 3rd party
> commandline program like "wget" (at least for windows, as it's not native).
>
>
I was looking into making a [httpsget]  external but the whole TLS thing
seems very difficult.
For my purposes on linux I use [shell] with wget to save the data to a
file, then open it with [binfile].
I was wondering if there is some cross-platform library to do the ssh, as
I'm sure implementing it from scratch would take forever and be very
error-prone. Not to mention doing it using vanilla objects

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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Martin Peach]

I ran this code on an arduino nano and sent it into a comport-print to
verify that it passes all the values without change:

void setup() {
  Serial.begin(115200);
  while(!Serial);
  Serial.println("OK");
}

void loop() {
  static uint8_t x = 0;
  Serial.write(x);
  delay(25);
  x++;
}

Maybe you could try that to be sure it's not your arduino code that's doing
it.

Martin

On Tue, May 14, 2019 at 11:14 AM Ingo  wrote:

> Whatever version was current in September 2018 is the version I have
> installed
> in the new setup.
> I wouldn't have been surprised about this behavior in the old version from
> 2011 - but 2018?
>
> I don't think there have been too many major changes since September 2018.
>
> As I had mentioned before: Sometimes it works - sometimes it doesn't .
>
> Ingo
>
>
>
> From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of Martin
> Peach
> Sent: Tuesday, May 14, 2019 4:20 PM
> To: pd-list@lists.iem.at
> Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> I just tried it here on both Windows 10 and Ubuntu with no issues. I can
> print
> every value from 0 to 255 from arduino and receive it unchanged in pd. I
> think
> possibly the OP is using an older version of comport.
>
> Martin
>
>
> On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig 
> wrote:
> On 14.05.19 15:47, Ingo wrote:
> > Could it be possible that the operating system does this even before it
> gets
> > to the comport object?
>
> well, those flags are supposed to control exactly what "the operating
> system does" in this respect.
>
> fgmasdr
> IOhannes
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Martin Peach]

I just tried it here on both Windows 10 and Ubuntu with no issues. I can
print every value from 0 to 255 from arduino and receive it unchanged in
pd. I think possibly the OP is using an older version of comport.

Martin


On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig 
wrote:

> On 14.05.19 15:47, Ingo wrote:
> > Could it be possible that the operating system does this even before it
> gets
> > to the comport object?
>
> well, those flags are supposed to control exactly what "the operating
> system does" in this respect.
>
> fgmasdr
> IOhannes
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Martin Peach]

It's odd that the lines

/* no post processing */
new->c_oflag &= ~OPOST;

and

/* always nocanonical, this means raw i/o no terminal */
new->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
_are_ present in open_serial() in comport.c.
That should disable all postprocessing of traffic.

Martin

On Tue, May 14, 2019 at 7:58 AM Roman Haefeli  wrote:

> On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
> > > > So, neither the OS nor the Pd or [comport] version seem to make
> > > > any
> > >
> > > difference.
> >
> > check my last two mails, I think this is macOS/Linux issue. can you
> > try my fix?
>
> Yeah, I will when I have access to an Arduino (or other serial device)
> and report back. Thanks for looking into this.
>
> Roman
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport and Windows 10

[Martin Peach]

Yes, just replace the 7 with whatever COM number you got. It works here on
windows10.

Martin


On Sun, May 12, 2019 at 10:40 PM Malcolm Jackson 
wrote:

> Hello,
>
> I'm currently going through ch.2 of Electronics for Digital Musicians by
> Alexandros Drymonitis. I'm at the part where he uses a [comport 7 57600]
> object in a serial_write-help patch to communicate with an arduino. I get
> this in the main window:
>
> [comport]: could not open device COM7:
>  failure(2) ERROR_FILE_NOT_FOUND
>
> [comport] opening serial port 7 failed!
>
> I tried sending the devices message to it and it found the port my arduino
> was connected to. Should I just change the port number to that? I've been
> looking around and seeing that comport doesn't work with windows 10 but
> haven't found a solution. I appreciate any help.
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Getting 32 bit floating point number from 4 sequential bytes

[Martin Peach]

On Sat, Apr 6, 2019 at 10:54 AM Arda Eden  wrote:

> With this method, I got the compiler warning about breaking the strict
> aliasing rule:
> uint8_t bytes[4] = {12, 34, 56, 78};
> float f = *(float*)bytes;
>
> Yes, modern c doesn't like type punning.


> This is my code, and for now, it is working properly. But I am not sure if
> this is an efficient way or not.
>
> typedef struct _xsensparse
> {
> t_object x_obj;
> uint8_t wrd[4];
> t_float o;
> t_outlet *f1_out, *f2_out;
> } t_xsensparse;
>
> static void xsensparse_list(t_xsensparse *x, t_symbol *s, int argc, t_atom
> *argv)
> {
> for(int i=0; i x->wrd[i]=(uint8_t)atom_getfloat(argv+3-i);
> memcpy(>o, >wrd, 4);
> }
> post("%f",  x->o);
> outlet_float(x->f1_out, x->o);
> }
>
>
I think the memcpy statement should be outside the for loop. As it is, it
operates the first three times uselessly.
Using a union would be a bit more efficient as it doesn't copy any memory.

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

Re: [PD] Getting 32 bit floating point number from 4 sequential bytes

[Martin Peach]

On Sat, Apr 6, 2019 at 10:06 AM Christof Ressi 
wrote:

> While type punning through unions is allowed in C, the only way which
> works in both C and C++ (without breaking the strict aliasing rule) is
> using memcpy. In such case, the call to memcpy will completely optimized
> away by every decent compiler.
>
>
But Pd is written in c, so no problem. How does the memcpy thing work? It
is also ANSI c. To m it looks just as 'dangerous' as the union method,
which I wouldn't call type-punning. 'Raw' type punning would be like:
uint8_t bytes[4] = {12, 34, 56, 78};
float f = *(float*)bytes;
But isn't that basically the same as what memcpy does?


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

Re: [PD] non-socket (88)

[Martin Peach]

On Sun, Feb 17, 2019 at 11:16 AM michael strohmann 
wrote:

> but one can issue arbitrary IP addresses, and the obejct will tell you it
> established connection.
> i guess this is consistend with the UDP protocol
>
It didn't 'establish a connection', it just opened a socket on the local
machine. Until you send something there is no communication whatsoever with
the remote socket.

Martin

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

Re: [PD] Using netsend to send url / text to turn a device on and off

[Martin Peach]

On Thu, Jan 24, 2019 at 11:36 AM RT  wrote:

>
> I'm trying to turn on and off a device using Pd by sending a URL. At the
> moment to turn the device on I just type in a url in the browser and to
> turn it off I type in another one url .
> To turn the device on I send http://192.168.1.123/relay/0/?turn=on
> To turn the device off I send http://192.168.1.123/relay/0/?turn=off
>
> If you don't have to use vanilla Pd it's easier to use [httpreq] and
[tcpclient].

Martin


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

Re: [PD] [PD-announce] PD 0.49-0test1 released

[Martin Peach]

On Tue, Sep 11, 2018 at 12:40 PM Alexandre Torres Porres 
wrote:

> I'm having issues with the test version:
> https://github.com/pure-data/pure-data/issues/443
>
> anyone else?
>
>
On Win7 with internal sound card, ASIO test tone 440Hz sounds all wrong,
sort of like a slowly rotating farting dinosaur.
MMIO works fine.

Martin.
















> Em ter, 11 de set de 2018 às 12:55, José de Abreu 
> escreveu:
>
>> hello, one question i always forget to ask:
>>
>> Why the shortcut to create horizontal slider changed from 0.47 to 0.48?
>>
>> it was shift+ctrl+h and changed to shift+ctrl+j
>>
>> (btw, i'm on linux, ubuntu studio, if it is needed)
>>
>>
>> Em ter, 11 de set de 2018 às 12:14, José de Abreu 
>> escreveu:
>>
>>> Liam, you can read about all the new commands here
>>>
>>> https://github.com/pure-data/pure-data/pull/374
>>>
>>
>> And triggerize isn't "documented" in there, you can use it with ctrl+t in
>> an object that has fanouts (and then if you need you can use swap
>> connections to organize all the cords after)
>>
>>
>>
>>>
>>>
>>> Em Ter, 11 de set de 2018 11:35, Liam Goodacre 
>>> escreveu:
>>>
 I'm thrilled about some of these updates! Infinite undoing, [savestate]
 and backslashes are really great additions.

 Here are a couple of notes from my first half-hour playing around with
 it.


1. I'm getting a lot of "zexy: already loaded" error messages. It
seems that they come every time you load a new abstraction with [declare
-lib zexy] in it. Is this a bug, or has the expected usage of [declare]
changed?
2. Are the backslashes working as intended? If I print *[\; \; \$
\$ \, \,(* I get "*; \\; $ $ \\, \\,*". I'm not sure what the exact
usage is supposed to be, but this output seems confusing.

 Also, is there a guide to the new intelligent patching features? I've
 seen the videos, but would like to be able to study it in more detail.
 --
 *From:* Pd-list  on behalf of Miller
 Puckette 
 *Sent:* 11 September 2018 06:23
 *To:* pd-annou...@iem.at
 *Subject:* [PD] [PD-announce] PD 0.49-0test1 released

 The first test version of Pd 0.49-0 is available on
 http://msp.ucsd.edu/software.htm
 or (source only) via github: https://github.com/pure-data/pure-data

 cheers
 Miller



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

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

Re: [PD] feature request: [array search]

[Martin Peach]

On Tue, Sep 4, 2018 at 5:22 PM Roman Haefeli  wrote:

> Hi again
>
> While we are at it: Wouldn't an [array search] be an immensely useful
> object?
>
>
There is [tabfind] in mrpeach. Does that work for you?

Martin

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

Re: [PD] Random

[Martin Peach]

On Thu, May 31, 2018 at 3:09 PM, hans w. koch  wrote:

> but couldn´t that pi limitation worked around by a loadbang -delay combo
> to read a date, once the system has established one?
> would need mention in the helpfile though.
>
> The pi might not be connected to any network, in which case it will always
start at Jan 1, 2000.
/dev/random may not be usable right at startup as it needs time to
accumulate entropy, .dev/urandom is guaranteed to give some sort of random.
Reading a few bytes from /dev/urandom into a table then combining them into
a float or long int seems like a better idea.
There's an equivalent method in the WIndows API (SystemPrng), but it would
have to be coded into an external since it's not a file like in linux.

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

Re: [PD] Random

[Martin Peach]

On Wed, May 30, 2018 at 10:17 AM, Jean-Marie Adrien  wrote:

> Hi everyone,
> trying to open a patch with a different text on screen each time random.
> Used random object as always since 20 years with a loadbang.
> Discovered that this loadbang/random seems to generate always the same
> result on opening
> :)
> What is the correct way to get a random digit on patch load within say 30
> choices ?
>

This patch uses [time] to seed the random sequence.

Martin
#N canvas 681 153 450 443 16;
#X obj 121 96 time;
#X obj 145 133 *;
#X obj 133 169 *;
#X obj 121 207 *;
#X floatatom 121 242 9 0 0 0 - - -;
#X obj 229 81 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 121 275 seed \$1;
#X obj 121 363 print >>>;
#X obj 74 22 loadbang;
#X obj 121 321 random 30;
#X obj 74 59 t b b;
#X connect 0 0 3 0;
#X connect 0 1 2 0;
#X connect 0 2 1 0;
#X connect 0 3 1 1;
#X connect 1 0 2 1;
#X connect 2 0 3 1;
#X connect 3 0 4 0;
#X connect 4 0 6 0;
#X connect 5 0 0 0;
#X connect 6 0 9 0;
#X connect 8 0 10 0;
#X connect 9 0 7 0;
#X connect 10 0 9 0;
#X connect 10 1 0 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] 1 / 0 = 0?

[Martin Peach]

On Thu, May 24, 2018 at 12:43 PM, Alexandre Torres Porres 
wrote:

> Many math objects in pd have protection against nan/inf, not only in the
> audio control. It is the official policy
>
> I think it makes more sense to use FLT_MAX (1E+37) for +infinity, not
zero. For continuity with adjacent values. See attached patch.

Martin
#N canvas 270 322 450 300 10;
#X obj 191 112 / 1;
#X msg 179 52 1 1e-037;
#X obj 225 184 print;
#X floatatom 140 203 9 0 0 0 - - -;
#X connect 0 0 2 0;
#X connect 0 0 3 0;
#X connect 1 0 0 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] 1 / 0 = 0?

[Martin Peach]

On Thu, May 24, 2018 at 10:57 AM, Christof Ressi 
wrote:

there's no other sane way to handle division by 0 in the audio domain since
> the result must be a number and there are only two options: output 0 or
> some ridiculously large number (which would be quite dangerous).
>

Yes, but if you try division by a very small number close to zero you still
get very large numbers that audio hardware will clip to +-1; the
singularity at zero is weird.

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

Re: [PD] Reason for not allowing '{' and '}' in Pd?

[Martin Peach]

On Mon, May 14, 2018 at 7:31 AM, Zack Lee  wrote:

> Hi, I'm trying to add a Lua scripting feature for my external which will
> allow users to write and run Lua scripts directly in pd as object arguments
> similar to how [expr] object works.
>
> Maybe you are no aware that you can right-click a pdlua object and select
'open' to open a text editor.
Or maybe this is not what you want...

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

Re: [PD] PdLua for ARM

[Martin Peach]

On Sat, May 12, 2018 at 9:43 AM, Alexandros  wrote:

> In deken there's no binary of PdLua for ARM. In the README for the Linux
> binary I read this:
>
> "1. edit Makefile.static to configure your PLATFORM and PDINCLUDE"
>
> But there's no Makefile or any .c file (there's a pd.lua file though).
> What do I need to compile PdLua for ARM? Which Makefile, any sources
> that might not be included in the available packages?
>
> On debian systems, you can install the package pd-lua.
If you need to compile it yourself, the Makefile will be in the source
directory along with the pdlua.c file.
I found a fork of it here:
https://github.com/agraef/pd-lua
so I'm not sure which is the latest and best version.
The last one I worked on is here:
https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/
externals/loaders/pdlua/

Martin

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

Re: [PD] pow/pow~ and negative input, a fix proposal

[Martin Peach]

On Wed, May 9, 2018 at 1:13 PM, Alexandre Torres Porres <por...@gmail.com>
wrote:

>
> 2018-05-09 13:53 GMT-03:00 Martin Peach <chakekat...@gmail.com>:
>
>>
>>> I just tried this in Max6:
>> [pow 2] with a negative input gives a correct positive result.
>> [pow 0.5] with negative input sets a floatnumberbox to 'nan',
>>
>
> yeah, but try it with [pow~] in max, you'll see that it will filter it out
> and make it output "0", in the same way I was telling you about the other
> signal objects that can generate inf/nan (I gave the example of atanh~).
> Currently, it seems only signal bitwise operator objects in max can
> potentially create inf/nan, and they have a [bitsafe~] object to deal with
> that (one which we also cloned for cyclone).
>

It makes sense for signal objects to give zero, to avoid giant spikes in
the audio, but control objects are not only used for audio, they ought to
give something more truthful, maybe just post an error message to the
console if there is no trapping mechanism that can be constructed in a
patch.


>
>
>> but [print]s the value '-1.#IND00'.
>>
>
> are you on windows?
>

Yes. What does max print on a Mac?

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

Re: [PD] pow/pow~ and negative input, a fix proposal

[Martin Peach]

On Wed, May 9, 2018 at 10:38 AM, Alexandre Torres Porres 
wrote:

> You know, now that you the inability to deal with nan/inf in pd, such as
> in [select] came up, it makes total sense to avoid them in Pd and I can see
> where that comes from.
>
> By the way, filtering out nan/inf is quite common in Max for audio
> signals, and in cyclone we needed to check that in objects like the trig
> functions (for instance  cyclone/atanh~ outputs 0 for input values <= -1 or
> >=1). And the case for doing that in audio signals is strong, as people say
> inf/nan is not good if it reaches your speakers and stuff.
>
> I was still unsure about why doing that for cnotrol numbers as well, but
> what's the point in generating them if your system doesn't handle it well,
> right? In the case of [pow], "0" is a good limit value to clip your output,
> it makes sense since you can't get negative numbers but you can reach 0!
>
> I just tried this in Max6:
[pow 2] with a negative input gives a correct positive result.
[pow 0.5] with negative input sets a floatnumberbox to 'nan', but [print]s
the value '-1.#IND00'.
 In max, neither of these works in a [sel].

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

Re: [PD] pow/pow~ and negative input, a fix proposal

[Martin Peach]

On Tue, May 8, 2018 at 9:28 PM, Alexandre Torres Porres <por...@gmail.com>
wrote:

> 2018-05-08 18:05 GMT-03:00 Martin Peach <chakekat...@gmail.com>:
>
>> On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres <por...@gmail.com
>> > wrote:
>>
>>> ...
>>> I personally cannot think of any use case where someone relies on
>>> pow(-1, 2) generating "0", it just seems wrong to me (i.e. a bug) and
>>> allowing it to do that wouldn't break things.
>>>
>>> Maybe add another outlet for the imaginary part?
>>
>
>  but simply  pow(-1, 2)  does not generate an imaginary part, right?
>
> Right, sorry I was thinking of pow(-1, 0.5). pow(-1,2) should give 1.
Useful if you wanted to make a parabolic waveform in a table or something
like that. And I think pow(-1, 0.5) should give a 'NaN' instead of 0 if
we're sticking to Real numbers. I'm not sure if something like [select NaN
Inf -Inf] works in Pd. It doesn't give any error on creation but how to
generate the input?
So ideally this:

[-1{
|
[pow 0.5]
|
[sel NaN]
|  |

would emit a bang from the left outlet.

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

Re: [PD] pow/pow~ and negative input, a fix proposal

[Martin Peach]

On Tue, May 8, 2018 at 2:07 PM, Alexandre Torres Porres 
wrote:

> ...
> I personally cannot think of any use case where someone relies on pow(-1,
> 2) generating "0", it just seems wrong to me (i.e. a bug) and allowing it
> to do that wouldn't break things.
>
> Maybe add another outlet for the imaginary part?
Martin
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [vcf~] with resonance?

[Martin Peach]

On Wed, Apr 25, 2018 at 12:46 PM, William Huston 
wrote:

> Yes, thanks for the detailed response, Ed!
>
> I was hoping for some guidance for a bolt-on method for adding resonance
> to vcf~,
> but maybe it's not so easy? or the wrong approach?
>
> My error was thinking resonance was implemented with feedback.
>
> I don't think you were wrong.


> From this video, it looks like resonance is caused by a bump in the filter
> shape at the cutoff frequency:
> https://youtu.be/XA_WnyA7D6k
>
> The bump in the filter response is a manifestation of resonance caused by
feedback (the electronotes paper explains it as moving the poles toward the
imaginary axis as feedback increases).

An analog-synth-like filter can be made with 4 [lop~]s in series with a
[send~] at the output and a
[receive~]
|
[*~ -0.9]  <-change this number to set resonance (between 0 and -1)
|
[clip~ -1 1] <- stops it from blowing up, but gives distortion with too
much feedback
|
on the input. The main problem is that the resonance value changes with
filter cutoff frequency. Also Pd's number boxes don't have fine enough
resolution; I use negative values from 0-2 then divide by 1 to get
better control.

Martin
#N canvas 306 47 732 597 10;
#X obj 231 231 lop~ 440;
#X obj 231 274 lop~ 440;
#X obj 231 311 lop~ 440;
#X obj 231 351 lop~ 440;
#X obj 231 417 dac~;
#X obj 308 349 hsl 128 15 0 127 0 1 empty empty empty -2 -8 0 10 -4034
-1 -1 7700 1;
#X obj 305 373 / 128;
#X obj 230 388 *~;
#X obj 133 74 r~ \$0-fb;
#X obj 136 437 s~ \$0-fb;
#X obj 133 101 *~ -1;
#X obj 231 171 noise~;
#X obj 285 163 hsl 128 15 0 127 0 1 empty empty empty -2 -8 0 10 -4034
-1 -1 2300 1;
#X obj 282 187 / 128;
#X obj 232 204 *~;
#X obj 133 128 clip~ -1 1;
#X obj 197 84 / 1;
#X obj 338 217 nbx 7 14 -1e+037 1e+037 0 1 empty empty empty 0 -8 0
10 -4034 -1 -1 229 256;
#X obj 197 54 nbx 7 14 -2 0 0 1 empty empty empty 0 -8 0 10 -4034
-1 -1 -16960 256;
#X obj 103 221 vsl 15 128 0 100 0 0 empty empty empty 0 -9 0 10 -260097
-1 -1 12549 1;
#X obj 103 194 env~ 64;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 3 0 7 0;
#X connect 3 0 9 0;
#X connect 5 0 6 0;
#X connect 6 0 7 1;
#X connect 7 0 4 0;
#X connect 7 0 4 1;
#X connect 8 0 10 0;
#X connect 10 0 15 0;
#X connect 11 0 14 0;
#X connect 12 0 13 0;
#X connect 13 0 14 1;
#X connect 14 0 0 0;
#X connect 15 0 0 0;
#X connect 15 0 20 0;
#X connect 16 0 10 1;
#X connect 17 0 0 1;
#X connect 17 0 1 1;
#X connect 17 0 2 1;
#X connect 17 0 3 1;
#X connect 18 0 16 0;
#X connect 20 0 19 0;
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] write tempo change with [midifile]?

[Martin Peach]

On Sat, Feb 10, 2018 at 7:48 PM, Martin Peach <chakekat...@gmail.com> wrote:

> On Sat, Feb 10, 2018 at 1:49 PM, tim vets <timv...@gmail.com> wrote:
>
>> I seem to be getting closer
>> [255 81 3 $1 $2 $3( seems to do the trick, (the 3 was necessary to
>> designate the 3 following bytes...)
>> still not sure why [255 81 3 7 161 32( does not result in 120bpm but
>> "120qpm" and 80bpm...
>>
>
> Probably because numbers greater than 127 must be formatted in
> 'variable-length quantity' form, where the number is broken up into 7-bit
> pieces and all the pieces except the last have the high bit set, so decimal
> 50 in hex is 7A120, or in binary 0110010, becomes 1000
> 1110 0010, or 158 194 32 (if I didn't make any mistakes along the
> way). Using calculator in programmer mode is useful here.
>

But for meta events, numbers are stored as is, in big-endian order, not as
variable-length,, so [ 255 81 3 7 161 32 ( should work properly.

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

Re: [PD] write tempo change with [midifile]?

[Martin Peach]

On Sat, Feb 10, 2018 at 1:49 PM, tim vets  wrote:

> I seem to be getting closer
> [255 81 3 $1 $2 $3( seems to do the trick, (the 3 was necessary to
> designate the 3 following bytes...)
> still not sure why [255 81 3 7 161 32( does not result in 120bpm but
> "120qpm" and 80bpm...
>

Probably because numbers greater than 127 must be formatted in
'variable-length quantity' form, where the number is broken up into 7-bit
pieces and all the pieces except the last have the high bit set, so decimal
50 in hex is 7A120, or in binary 0110010, becomes 1000
1110 0010, or 158 194 32 (if I didn't make any mistakes along the
way). Using calculator in programmer mode is useful here.
 I need to add a meta method so you can write meta events without having to
do that.

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

Re: [PD] md5 object?

[Martin Peach]

md5 is defined in internet rfc1321, (see
https://www.ietf.org/rfc/rfc1321.txt) which includes c code to implement
it, so it should be fairly straightforward to wrap into a pd external.

Martin

On Thu, Feb 8, 2018 at 12:09 PM, Johnny Mauser via Pd-list <
pd-list@lists.iem.at> wrote:

> I have got the pjlink thing to work through [shell]. It is not ready to
> share yet. And of course everything would have been easier with a dedicated
> md5 object.
>
> Am 08.02.2018 3:17 nachm. schrieb "Marco Hugo Schretter" :
>
>> hi leute,
>>
>> thanks for the input. i'll tidy up my patch and post what i have
>> soon (and go on with development).
>>
>> +1 for hashing lib
>>
>> ciao aus dd,
>> m
>>
>>
>> Am 08.02.18 um 14:51 schrieb me.grimm:
>>
>>>  >> i'd suggest to make it a general hashing library, that implements
>>> multiple algorithms,
>>>
>>> +1
>>>
>>> i started something once but like everything i start thats about all
>>> that seems to happen:
>>> https://github.com/megrimm/pd-hmacsha256
>>>
>>> maybe a starting point though?
>>>
>>>
>>> On Thu, Feb 8, 2018 at 7:10 AM, IOhannes m zmoelnig >> > wrote:
>>>
>>> On 2018-02-08 04:22, Marco Hugo Schretter wrote:
>>> > i'll try to do some documentation soon so maybe we can
>>> > solve the md5 thing. there are some opensource projects
>>> > which provide all the basic c/c++ code for an md5 external as
>>> > i found out. time will come.
>>>
>>> if you (or anybody else) starts such a library, i'd suggest to make
>>> it a
>>> general hashing library, that implements multiple algorithms, not
>>> only
>>> "md5". (i think practically no new software uses MD5; it's supported
>>> (everywhere) for legacy purposes).
>>>
>>> fgmasdr
>>> IOhannes
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at  mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>>> 
>>>
>>>
>>>
>>>
>>> --
>>> 
>>> m.e.grimm, m.f.a, ed.m.
>>> syracuse u., tc3
>>> megrimm.net 
>>> 
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] glitches when streaming UDP

[Martin Peach]

On Wed, Feb 7, 2018 at 10:21 AM, Roman Haefeli <reduz...@gmail.com> wrote:

> On Mit, 2018-02-07 at 09:46 -0500, Martin Peach wrote:
>
> > Maybe there's a way to force all the Pd-related processes to run on
> > the same core, as it could be that the transfer of memory from one to
> > the other causes glitches, so if jackd is on a different core than Pd
> > there will be latency as they transfer access to the buffer from one
> > to the other. Just guessing...
>
>
> I tried:
>  * turning hyperthreading off
>  * putting pd and jackd on the same core
>  * putting pd and jackd on different cores
>
> but those configurations don't seem to affect the current situation at
> all.
>
> There's also wish, the tcl/tk component.


> Please someone correct me here, but I think it does not matter if pd
> and jackd run on the same core, since they seem to communicate through
> /dev/shm, so there is no gain to be made by being closer together. I'd
> say it makes even sense to separate them so that overall more CPU power
> is available for both.
>
> Also, the fact the running x instances of 'yes' in the background helps
> indicates that the problem is not the communication between pd and
> jackd.
>
> Yes it sounds like the things go to sleep when nothing happens for a few
nanoseconds or something.
It should be documented somewhere on kernel.org.

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

Re: [PD] glitches when streaming UDP

[Martin Peach]

On Wed, Feb 7, 2018 at 9:26 AM, Roman Haefeli  wrote:

> On Mit, 2018-02-07 at 14:32 +0100, Lorenzo Sutton wrote:
> > On 30/01/2018 11:07, Roman Haefeli wrote:
> > >
> > > On Mon, 2018-01-29 at 10:25 +0100, Roman Haefeli wrote:
> > >
> > > >
> > > > I'm working on a patch that transmits audio through UDP. The
> > > > patch
> > > > runs
> > > > totally smooth on macOS (10.10 and 10.11) with Pd 0.48-1 and JACK
> > > > as
> > > > back-end. On the Linux machines I tested (all Ubuntu 16.04) with
> > > > the
> > > > same version of Pd I get a lot of glitches, although I'm using
> > > > very
> > > > similar Jack settings (128 frames/period, 3 periods).
> > > Update:
> > > My personal, somewhat outdated laptop from 2007 has absolutely
> > > stable
> > > performance with same patch, same Pd version, same OS, same kernel.
> > > To
> > > be clear: It's only Pd that performs well on one computer and not
> > > so
> > > well on others. I get glitch-free audio with Ardour on all tested
> > > computers. So I wonder what circumstances affect specifically Pd.
> > > It's
> > > a pity the most powerful computer I have access to is in its
> > > current
> > > state not suitable for Pd projects :-(
> > One thing to try from totally non-scientific personal experience
> > would
> > be to look into CPU scaling stuff when using Pd. The fact that an
> > old
> > machine works well possibly hints that this might be the culprit, so
> > worth trying. I experimented with this when pushing my Granita
> > granulator with realtime input being fed to the buffer and trying to
> > eliminate as much as possilbe "smart" CPU stuff improved things quite
> > a
> > lot... On my previous laptop I could set various governors on my
> > current
> > one there is only powersave and performance, the latter should work,
> > but
> > also trying to set a fixed frequency... You have to experiment a bit.
>
> Thanks for mentioning that. Setting the governor to 'performance' for
> all cores is part of my standard setup when going into 'performance'
> mode with Pd. Even on my old laptop (CPU: Intel Core 2 Duo T8300) I
> need the scaling governor to set to 'performance'. To my non-scientific
> eye it looks like Pd in realtime mode has a higher priority than the
> service controlling CPU frequency, so that switching to a new frequency
> would happen only after Pd's need for it is over.
>
> The issue I'm having here is not related to CPU frequency scaling (at
> least not exclusively). Even when all cores run under 'performance' and
> at maximum clock speed, I get crackles with the new laptop (CPU: Intel
> Core i5-7300U). Yet, the only reliable way known to me so far to get
> running Pd crackle-free is to run four instances of 'yes > /dev/null
> &'. This seems to keep whatever resource Pd needs to access quickly
> awake and available. While those four instances of 'yes' are running in
> the background, it doesn't matter what governor I set since they keep

the cores at their maximum frequency anyway.
>
>
Maybe there's a way to force all the Pd-related processes to run on the
same core, as it could be that the transfer of memory from one to the other
causes glitches, so if jackd is on a different core than Pd there will be
latency as they transfer access to the buffer from one to the other. Just
guessing...

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

Re: [PD] macOS 64 bit only soon

[Martin Peach]

On Sun, Jan 28, 2018 at 9:26 AM, Jean-Marie Adrien 
wrote:

> cryptic for me too :)
> another (stupid) question :
> is GEM available in 64bits ?
> still using *old school GEM on pd extended* on my side, in parallel with
> PD-47-64bit pd for sound…
> jm
>
> I don't know what OS you're on, but if you install packages on 64-bt linux
they will be 64-bit. If you build them from source on a 64-bit machine they
will be 64-bit by default.
Although it is rather difficult to build pd-extended because of all its
dependencies, it should be possible to make a 64-bit version. There is no
explicit use of the -m32 flags in any of its makefiles.

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

Re: [PD] macOS 64 bit only soon

[Martin Peach]

On Fri, Jan 26, 2018 at 8:29 AM, Dan Wilcox  wrote:

> To coincide with the work people are doing on 64 bit Windows builds of Pd,
> it looks as though Apple is stepping up it's move toward 64 bit only in the
> next version of macOS: https://www.macrumors.com/2018/01/24/macos-high-
> sierra-32-bit-app-warning/
>
> We've had 64 bit macOS Pd builds for a long time now, but now we need 64
> bit external builds on deken to go with it. This will also likely mean that
> Pd-extended will no longer run on macOS 10.14 next year.
>
> Is the only difference from 32-bit Pds that the structs are 64-bit aligned
(i.e.doubled in size), or are the t_float and so on also now 64-bit?

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

Re: [PD] Gem: can't load library -- FIXED. Download msvcr71.dll

[Martin Peach]

On Mon, Dec 11, 2017 at 7:06 PM, Samuel Burt  wrote:

> Thanks, Lucas. That's exactly what I needed and couldn't find.
>
> That last exchange was from 2016. Any reason the dll isn't included now?
> Is it some kind of licensing issue?
>
>
Since Win10 it's not considered a system file anymore.
The implementation of the c-language runtime library has changed, so
applications from the past need to include the msvcrt dll in the same
directory as the application that was built against it, see:
https://support.microsoft.com/en-us/help/326922/redistribution-of-the-shared-c-runtime-component-in-visual-c

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