Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[Roman Haefeli]

On Don, 2018-03-08 at 17:09 +0100, IOhannes m zmoelnig wrote:
> we are proud to announce a major overhaul of the deken fileformat.

[...]

> - (optionally) uninstall libraries before re-installing them

Yay!

Thanks for your work. Nice development of matters.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] deken v0.3.0: new fileformat for library packages

[Roman Haefeli]

At the risk of not being helpful to the issue by adding another
opinion, I disagree. Or rather: I do not really follow you. I don't see
any problem with deken installing into a hidden folder. It's a pretty
common thing on all OSs. Just a have a look at the contents of
~/Library, %AppData%\, ~/.local/ .

You say: "Newbies have troubles finding the folder"

I say: "Newbies shouldn't have to know about it all"

Ideally (in my notion of how things would ideally be), there is nothing
to be done manually in that folder. Ideally, deken is a management
interface  for the user to install, enable, disable, remove libraries.
It doesn't matter where it does all at. You would install a library and
this is enables you to simply do [declare -std[path|lib] yourlib] to
use it in your patch. You shouldn't have to know more. It looks like
we're getting closer to that with all the efforts done recently.

Roman 

On Don, 2018-03-08 at 14:27 -0300, Alexandre Torres Porres wrote:
> > - set installation path (suggesting Pd's default search paths, and
> > offering to create those that are missing)
> I wouldn't know if, officially, there are such things as "Pd's
> default search paths". But then it's clear you mean "standard paths",
> instead of "default search paths", right? Then again, this raises a
> few issues. Cause, well, under a recent discussion, it was considered
> that only the "extra" folder was supposed to be the standard folder,
> so there are not supposed to be other "standard paths". In other
> words, it ain't plural, just a singular standard path option, and one
> that comes always with Pd and doesn't need to be created. 
> 
> So yeah, what had the need to be created was one folder like that
> weird and hidden mac folder (~/Library/Pd)... but access to it would
> still be difficult (as it is invisible). Hence, we have a new folder
> now (~/Documents/Pd) but that is not a "standard path", just a
> "regular" path. And I see now "deken" is offering me to create such
> folders like ~/Library/Pd, after a long discussion that led to the
> idea we shouldn't use them no more. See this: https://github.com/pure
> -data/pure-data/pull/139
> 
> I know I keep bringing this up here and there, but I think it's a
> very important detail that can cause many confusions and there is
> still a lot of inconclusiveness out there, and we're not doing much
> about it and letting the confusion grow. Now, I was also one of the
> people who was requesting such a feature several times in Deken, it's
> all I ever wanted, but the game has really changed because of such
> recent discussions. 
> 
> So now we can finally easily create this folder, but it is still
> invisible and inaccessible to newbies, so not much advantage there.
> Cause if you need to know how to navigate to that folder, you also
> know how to create it. So this partially fixes the issue. What was
> needed there was create it and easily navigate to it, but instead, it
> was just easier to go to a new folder instead, like ~/Documents/Pd -
> as we did!
> 
> So we have this new standard now that was designed exactly to fix
> this issue. So this new feature is pointless now, as a new solution
> (using ~/Documents/Pd) was made, so it is trying to fix an issue (but
> not in fully fixing it) that has already been fixed and has been in
> use since 0.48-0! But more importantly, this extra folder has been
> explicitly declared as a non intentional extra "standard path". See
> how much confusion this promotes?
> 
> So, given all that, I'm even suggesting a Pull Request to clear this
> up for good, it's here: https://github.com/pure-data/pure-data/pull/1
> 83
> 
> See also: https://github.com/pure-data/pure-data/issues/184 which
> discusses the behaviour of [declare] and how we could just use "-
> path" and forget about "-stdpath" 
> 
> And leaving "~/Library/Pd" aside, the other extra standard path
> option here on the mac: "/Library/Pd" doesn't even get created with
> the new deken plugin, I figure because it may require admin powers,
> so it doesn't really help either.
> 
> Now, I don't know how the plugin works, but I may assume it gets
> these paths from Pd, so maybe if my Pull Request gets accepted, no
> change needs to be made in the Deken plugin and it'll just stop
> showing them...
> 
> Anyway, what I see from this update with this issue is that we have
> added more unnecessary complexity. Things were cleaner and simpler
> before. But well, I don't consider this a "deken" issue, but a deeper
> Pd issue that is popping up in deken and other different places. 
> 
> That is to say that I'm really happy with the new improvements in
> deken, congratulations, it is quite exciting!
> 
> cheers
> 
> 
> 
> 2018-03-08 13:09 GMT-03:00 IOhannes m zmoelnig :
> > we are proud to announce a major overhaul of the deken fileformat.
> > 
> > TL;DR to download new deken packages, you will need at least
> > version
> > v0.3.0 of the deken-plugin (Pd-0.48-1 includes deken-v0.2.4).
> > When searching ex

Re: [PD] [convolve~] version 0.11 testing

[Roman Haefeli]

On Mon, 2018-03-19 at 20:58 +, Lucas Cordiviola wrote:
> Hi William,
> Are you aware of --> https://github.com/pure-data/pd-lib-builder
> This will ease building on many platforms including the upcoming
> windows64bit.
> You will like it.
> : )

Just in case, you're going to use pd-lib-builder: I already uploaded an
earlier version of convolve~ to deken and thus added a pd-lib-builder
Makefilee because it suits my workflow, if you're interested:

https://github.com/reduzent/pd-convolve/blob/master/Makefile

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] pad sound with Pd

[Roman Haefeli]

Hey all

I'm wondering how to do the most silky pad sound in Pd. I'm curious
what strategies people use and am also interested in patches if people
don't mind sharing. It came up because of a track I was working on that
I was only half happy with the pad part.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pad sound with Pd

[Roman Haefeli]

On Die, 2018-03-20 at 22:09 +0100, Dan Wilcox wrote:
> Try s_pad in rjlib: https://github.com/rjdj/rjlib

Oh yeah. There's a lot that can be tweaked with this one. Will have to
try it out in a polyphony setup. Anyway, there are a lot of interesting
sounds to check out. Thanks for pointing me to it (I already had it
installed).

> Or ask this guy 0_O https://www.youtube.com/watch?v=T2Y0ftqDUlE

Yeah, I saw this one. Amazing!

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] reporting the dimensions of a symbol / float atom

[Roman Haefeli]

On Mit, 2018-03-21 at 13:08 +, Liam Goodacre wrote:
> The problem is that when I move from one system to another, many of
> my abstractions fail to display correctly, because the atoms fall
> outside of the GOP area. (See the attached image: the GOP area was
> set in 0.47, but it won't display in 0.48). The Context library uses
> a lot of tightly fitted GOPs (for better or worse), and I'm looking
> for a solution so that I can guarantee that they will display
> correctly on all systems. Even if the PD font width is standardized,
> there is always the chance that somebody loads PD with the -font-
> weight bold flags, which would throw it off again.
> 
> An external object that reported the system standard dimensions would
> offer a solution, since you could then set the abstraction to resize
> itself according to the system.
> 
> I'm also open to other solutions, if anyone can think of them.

I'm in the same boat. This is the single-most important culprit I
experience with non-consistent font sizes. I think Dan did a great deal
of work to harmonize font and box sizes across platforms.

My strategy has been to wait until things are corrected on the Pd side
instead of trying to work-around those issues myself. So, I hope I can
stick with this strategy, because working-around it is so much work.
Personally, I'd rather have people agree on the notion that this should
be addressed in Pd than people who establish their own ways to mitigate
the problem.

So, if you ask me, please don't use any reporting of sizes ;-)

Is this still an issue with Pd 0.48-1? I thought not, but I might need
to check again.


Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] changing GOP size dynamically without dirty flag

[Roman Haefeli]

On Mit, 2018-03-21 at 13:08 +, Liam Goodacre wrote:
> An external object that reported the system standard dimensions would
> offer a solution, since you could then set the abstraction to resize
> itself according to the system.

This reminds of my finding, that when using 'donecanvasdialog' to
change the visual size of the GOP area, the abstraction is marked dirty
which leads to more dialogs when closing the patch.

Is there a way to adjust the GOP size without marking the instance of
the abstraction/patch dirty?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] changing GOP size dynamically without dirty flag

[Roman Haefeli]

On Mit, 2018-03-21 at 14:57 +0100, oliver wrote:
> > 
> > 
> > Is there a way to adjust the GOP size without marking the instance
> > of
> > the abstraction/patch dirty?
>
> [..] send it a message like this:
> 
> [donecanvasdialog 1 -1 3 0 -1 1 1 100 100 10 10, dirty 0(
> |
> [send YOURNAME]


Cool. It's never too late to learn new things. Many thanks :-)

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] reporting the dimensions of a symbol / float atom

[Roman Haefeli]

On Mit, 2018-03-21 at 18:52 +, Liam Goodacre wrote:
> It would certainly help me to have be able to query atom sizes. 

I see your point and the benefit of such a feature. Independent of
that, I'd like to be able to count on consistent box sizes across
platforms and future Pd versions. 

> BTW, we are talking about two different things here: font size and
> atom size. What is the relationship between them? In 0.48.1, the atom
> appears to have increased in height, suggesting that they are not
> always proportional.

Right. I was assuming those would be related, but my main concern is
about box size, exactly because of fitting atoms into GOP areas.

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] cannot 'upgrade' old patch

[Roman Haefeli]

On Don, 2018-03-22 at 07:44 +0100, ro...@dds.nl wrote:
> hi list,
> 
> i have old patches made with Pdext 42.5.
> when opened with Vanilla 48.1 i get lots of uncreated objects (of 
> course).
> 
> some of them i'm not able to 'repair'.
> e.g. [symbol2list]
> 
> i put in a [declare -stdpath -zexy -stdlib -zexy].

It should read:

[declare -stdpath zexy -stdlib zexy]

(without dashes before 'zexy').

> it's possible to create a new [symbol2list] object.
> 
> after saving, closing pd, opening again,
> the new object is not created.
> 
> what can i do to resolve this.

Let's hope the typo was the reason for this. If not, then this is odd.
I mean, if it works _before_ saving the patch, it is supposed to work
after re-loading. I'd run pd in verbose mode. You can add the startup
flag '-verbose' (without quotes) in your preferences. When loading
[symbol2list], check what it does and whether Pd is looking into the
right places.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Discussing, exchanging pd-generated music

[Roman Haefeli]

On Son, 2018-03-25 at 15:02 +0200, jlistshit wrote:
> OT question: What other list might exist to discuss/exchange etc
> mostly the music that people produce with PD, rather than the
> technical details? Open to all styles here, though with a focus on
> generative, electro-acoustic, composition, not very IDM interested.

Why not discuss it here? I don't know of any other list/forum/board.

I'd be interested in people posting and discussing their works here.
Not only music, but everything what people do with Pd.

What do others think about this? Is a separate "artistic" channel
necessary?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] add inlets to [ctlin]

[Roman Haefeli]

On Sam, 2018-03-31 at 14:18 +0100, mario buoninfante wrote:
> Hi all,
> 
> 
> is there any particular reason why on [ctlin] there are no inlets
> that 
> allow to change MIDI channel and control number on the fly?
> 
> do you guys think it would be useful to have it?

Probably, but when creating it without arguments, you receive messages
on all controllers of all channels. So you can dynamically filter by
controller and channel yourself. You could build an abstraction that
has an inlet for dynamically setting controller and channel.

Roman 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Roman Haefeli]

yawn.


On Son, 2018-04-01 at 17:42 -0300, Alexandre Torres Porres wrote:
> Hi, currently, if you want to use $0, you need an object cause it
> becomes "0" when it's inside messages.
> 
> Pd-l2ork and Purr Data implemented a way that $0 works in the same
> way as in objects than in messages, and I think it is a great
> feature, as many patches can be significantly simplified. I guess
> most Pd users here know what I'm talking about.

By implementing that, you would once forever prohibit the proper way to
expand $0 which is expanding to the selector of the message. That's why
I oppose your proposition. (Actually, it doesn't matter whether I'm
opposing it or not since I don't contribute any Pd code. But I can at
least point to the fallacies.)

I absolutely see the convenience of your proposition, but there would
be no good explanation for it. Consider it a bad coincidence that both
kinds of variables use a dollar prefix, there is nothing in common
between them (expanding to creation arguments versus expanding to atoms
of messages). Personally, I would totally find it convenient if Pi was
an integer number, it would make so many things so much easier. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Roman Haefeli]

On Mon, 2018-04-02 at 11:26 +0200, João Pais wrote:
> 
> For me, I can't count how many times I had to add a [$0], or a pack
> or some extra workaround before a message so that I could send
> messages to my variables (I hardly use variables without a $0).

I can't count how many times I had to loop back the outlet of a [+ 1]
to the right inlet of a [f ] to build counter. 

Apparently, you need to figure out the creation argument first before
you build a message using it. I don't see anything specially tedious
about this process. 

Why is nobody complaining about not being able to use the third
creation argument directly withing a message? What's the fuzz about the
$0?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Roman Haefeli]

On Mon, 2018-04-02 at 05:01 -0700, Derek Kwan wrote:

> > For me, I can't count how many times I had to add a [$0], or a pack
> > or
> > some extra workaround before a message so that I could send
> > messages
> > to my variables (I hardly use variables without a $0).
> > 
> > Joao
> I do face this too where I use $0 with all my [v]s and [s]s and [r]s
> and
> it does get to be a bit tedious BUT I'm not quite sure if mixing the
> two
> worlds and their rules are worth it...

Yeah! Ideally, there would be two different prefixes for message
expansion and creation argument expansion. THEN you could have it
convenient, #0 would expand to the message selector, $0 to the implicit
ID, $1 to the first creation argument, #1 to the first atom of the
incoming message, etc... And everyone would be happy.

I just see no way to go from here to there...

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [list] example3.pd crash on Pd-0.48.1 / Linux

[Roman Haefeli]

On Mit, 2018-04-04 at 02:52 +0900, Jonghyun Kim wrote:
> Hi list,
> 
> The problematic patch is:
> 
> pd/doc/5.reference/example3.pd

It's actually in the help of [list] in the serializer example.

> this patch only crashed on 0.48.1. It's ok on old version of Pd.
> 
> I don't know why?

It's a bug in the documentation. [list store] understands the 'get'
method, but not the 'range' method, it seems. I guess this was changed
somewhere along the development of [list store] and was forgotten to
adjust in the serializing example.

Change the message box to 'get $1 1' and it works.

Since you discovered this you might want to file a bug report about
this (unless Miller reads it here anyway). 


Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD on a Rasberry Pi

[Roman Haefeli]

Hey Jackson

On Mit, 2018-04-04 at 14:58 +, jackson re-al wrote:
> Someone reached out earlier to see if anyone had experience running
> PD on a Pi.
> 
> If anyone here could help out then please give me a shout - It would
> be much appreciated.

What OS is running on the RPi? Some more info about what you have and
what exactly you want to do would be nice.

If it's a Raspbian:

sudo apt install puredata

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Roman Haefeli]

On Die, 2018-04-03 at 13:52 +, Jonathan Wilkes wrote:
> > Why is nobody complaining about not being able to use the third
> > creation argument directly withing a message? What's the fuzz about
> the
> > $0?
> 
> $0 isn't part of the argument vector. 

It's certainly not part of the incoming message either. 

> It's a unique id automatically
> generated for a patch/abstraction which the user happens to access
> through a dollarsign variable.

Regardless of the the actual value, its meaning is 'this very
instance'. So, I still rather see it as an argument of the patch than a
part of the message. But we could go on like this forever, I suppose.

> That locality hack doesn't require that the unique id be fetched by
> an unused dollarsign arg. For example, you could reserve the keyword
> "let" such that a message box with "let token2" would get converted
> behind the scenes to "1003-token2".
> 
> When users for a decade have said they wanted $0 in msg boxes,
> they mean that they want to use Pd's notion of send-symbol locality
> inside message boxes. They want that instead of manually querying 
> the value of a reserved dollarsign variable and sending that value
> to the relevant message box in order to get "let" behavior.

I'm not opposing the feature. I criticize the proposed implementation. 

> Also, since "$0" is already being used for this purpose it doesn't
> make much sense to try to also get "$0" to refer to the selector. 
> You'd end up with inconsistent meaning where it fetches the 
> selector in msg boxes but not in object boxes.

That's an absurd argument. I already pointed out that dollar variables
are a totally different thing in messages and objects.

>  Plus you can 
> already get the selector of an incoming message with [list]

Similarly you can get the value of $0 into a message.
 
> whereas you cannot get an abstraction's selector (which would 
> be handy for error reporting). 

What is the selector of an abstraction? 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] shrinking subpatches!?

[Roman Haefeli]

On Don, 2018-04-05 at 22:55 +0200, Christof Ressi wrote:
> in the project I'm working on I have a couple of subpatches which
> shrink vertically whenever I close and open them... 
> I made a funny little patch to demonstrate the issue. can anyone
> reproduce this on his/her machine? 

I cannot reproduce the exact behavior here with Ubuntu 16.04 amd64, Pd
0.48-1, Fluxbox with non-standard window border and window title sizes.
But the subpatch moves downward with each iteration. This happens with
all canvasses that are narrow enough to have wrapped-around menus. I
wonder whether the shrinking is also caused by wrapped around menu. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] suggestion: $0 in messages

[Roman Haefeli]

On Don, 2018-04-05 at 21:17 +0200, Dan Wilcox wrote:
> test? https://github.com/pure-data/pure-data/pull/346

Better do than talk, hey? ;-)

Works fine and is definitely convenient. Can't see any disadvantage or
problem with compatibility, though it challenges my notion of how
things are supposed to be. When nobody is looking, I clandestinely
click a message box containing '$0' that has NOTHING CONNECTED TO ITS
INLET!  *shiver*  ;-)

Roman 

 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] purest_json: how to specify root CA or CA bundle when using SSL?

[Roman Haefeli]

Hey all

Somehow using HTTPS with purest_json just worked(tm) in Debian Jessie.
Now, that I had to compile purest_json myself, I'm having troubles
verifying the server. I'm getting:

    77 Problem with the SSL CA cert (path? access rights?)

when accessing a resource through HTTPS with [rest]. 

How can I tell [rest] where my certificate store lies? Or is there a
way to specify a root certificate?

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purest_json: how to specify root CA or CA bundle when using SSL?

[Roman Haefeli]

On Mit, 2018-04-25 at 11:04 +0200, IOhannes m zmoelnig wrote:
> On 2018-04-25 10:59, Roman Haefeli wrote:
> > 
> > Somehow using HTTPS with purest_json just worked(tm) in Debian
> > Jessie.
> > Now, that I had to compile purest_json myself,
> btw, what is wrong with the pd-purest-json Debian package?

Nothing. It seems to use the certificate store from the system already.
It works well for me. Thanks for pointing me to it.

> afaik, the version in buster 

I am on Debian stable (Stretch). The version of Buster doesn't matter
for me.

> is pretty up-to-date and using the correct
> Debian package for your distribution will magically get rid of all
> the
> dependency problems you experience.

Regarding my other mail: I'm not looking for a solution, as I don't
have a problem using the package from apt or compile my own. But I'm
curious to know whether it is possible as a Deken package maintainer to
address the problem of different versions of linked libraries.

> also, the pd-deken-apt package allows you to integrate apt packages
> in
> your deken search.

Which is a cool feature!

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purest_json: how to specify root CA or CA bundle when using SSL?

[Roman Haefeli]

On Mit, 2018-04-25 at 13:08 +0200, Roman Haefeli wrote:
> On Mit, 2018-04-25 at 11:04 +0200, IOhannes m zmoelnig wrote:
> > 
> > On 2018-04-25 10:59, Roman Haefeli wrote:
> > > 
> > > 
> > > Somehow using HTTPS with purest_json just worked(tm) in Debian
> > > Jessie.
> > > Now, that I had to compile purest_json myself,
> > btw, what is wrong with the pd-purest-json Debian package?
> Nothing. It seems to use the certificate store from the system
> already.

Actually, I would love to understand a bit more the magic behind it.
Why does purest_json/rest from apt correctly validate certs against the
system's CA store and the compiled version does not?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purest_json: how to specify root CA or CA bundle when using SSL?

[Roman Haefeli]

On Mit, 2018-04-25 at 14:11 +0200, Thomas Mayer wrote:
> 
> Maybe you could replace libcurl4-nss-dev with libcurl4-gnutls-dev or
> libcurl4-openssl-dev for compiling purest_json.

Ah, i see. When only libcurl4-openssl-dev is installed and the others
removed, the resulting [rest] successfully validates certificates.

So it seems, only the documation needs an update (not to
mention libcurl4-nss-dev)

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Piano roll sequence display

[Roman Haefeli]

On Mon, 2018-04-30 at 11:20 -0400, William Brent wrote:
> Has anyone done something like this using [struct]/[polygon], even
> just for sequence display purposes and not editable via mouse
> clicking/dragging? I did a quick search of the archives but haven't
> found anything.

There is unstep[1] in netpd, which is a sequencer abstractions that
some instruments use. It's only able to trigger notes and has no notion
of note lengths or velocity, but number of rows and columns can be
dynamically set. It's based on an abstraction called ungrid[2] which
works also outside the netpd context and which comes a with a proper
help.

[1] https://netpd.org/~roman/tmp/unstep.png
[2] https://github.com/reduzent/netpd-instruments/blob/master/abs/ungrid.pd

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] watchdog

[Roman Haefeli]

On Thu, 2018-05-03 at 06:29 +0200, michael strohmann wrote:
> Hello, 
> i wonder if it is possible to setup something on raspberry, so that
> the puredata-watchdog will restart pd-0.48.0 automatically?
> where could i look up the mechanics of this, unfortunatly i am not a
> unix crack…

Are you referring to the pd-watchdog binary, that comes with puredata-
core? Is your Raspberry Pi running Raspbian?

From what I understand, the purpose of the pd-watchdog is to pause Pd
in regular intervals when running in real-time mode. I think this is
measure to prevent Pd from locking up the system. Assume you
accidentally trigger an [until] without a stopping mechanism, thanks to
 pd-watchdog you're still able to move the mouse and quit Pd.

Is your goal to make sure that Pd is running at any time, so that it is
started again as soon as it stops?  Maybe you can achieve something
like this wit a shell script. I haven't tested this, but it might give
you an idea how to make it work:

---
#!/bin/sh

while true
do 
  # We start pd and send detach it from the terminal ('&')
  /usr/bin/pd -open yourpatch & 

  # we catch pd's process id
  pdpid=$!

  # now let's wait for the process to terminate
  wait $pdpid
  
  # once pd terminates, we start another iteration
  # of our while-loop
done
---

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] watchdog

[Roman Haefeli]

On Thu, 2018-05-03 at 09:42 +0200, Roman Haefeli wrote:
> On Thu, 2018-05-03 at 06:29 +0200, michael strohmann wrote:
> > Hello, 
> > i wonder if it is possible to setup something on raspberry, so that
> > the puredata-watchdog will restart pd-0.48.0 automatically?
> > where could i look up the mechanics of this, unfortunatly i am not
> > a
> > unix crack…
> 
> Are you referring to the pd-watchdog binary, that comes with
> puredata-
> core? Is your Raspberry Pi running Raspbian?
> 
> From what I understand, the purpose of the pd-watchdog is to pause Pd
> in regular intervals when running in real-time mode. I think this is
> measure to prevent Pd from locking up the system. Assume you
> accidentally trigger an [until] without a stopping mechanism, thanks
> to
>  pd-watchdog you're still able to move the mouse and quit Pd.
> 
> Is your goal to make sure that Pd is running at any time, so that it
> is
> started again as soon as it stops?  Maybe you can achieve something
> like this wit a shell script. I haven't tested this, but it might
> give
> you an idea how to make it work:
> 
> ---
> #!/bin/sh
> 
> while true
> do 
>   # We start pd and send detach it from the terminal ('&')
>   /usr/bin/pd -open yourpatch & 
> 
>   # we catch pd's process id
>   pdpid=$!
> 
>   # now let's wait for the process to terminate
>   wait $pdpid
>   
>   # once pd terminates, we start another iteration
>   # of our while-loop
> done
> ---

Actually, this is overkill. Since there is only one job to wait for,
the whole wait stuff is not necessary, as the examples from other list
members clearly show.

Peter's or Jack's examples are better.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] watchdog

[Roman Haefeli]

On Thu, 2018-05-03 at 11:56 +0200, Jack wrote:
> If you have several instances of Pd, it is also doable to do
> something
> like :
> 
> pd -open yourpatch1.pd &
> PID1=$!
> pd -open yourpatch2.pd &
> PID2=$!
> 
> while true
> do
> if [ ! -d /proc/$PID1 ]
> then
> pd -open yourpatch1.pd &
> PID1=$!
> fi
> if [ ! -d /proc/$PID2 ]
> then
> pd -open yourpatch2.pd &
> PID2=$!
> fi
> done

If I'm not mistaken, this hogs the CPU as it will run as many
iterations per second as possible. I think a 'sleep 1' would already
help.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PD won't run on Ubuntu 18.04

[Roman Haefeli]

On Fri, 2018-05-04 at 04:15 +, Liam Goodacre wrote:
> I can't get PD 0.48.1 to run on a fresh installation of 18.04 LTS. It
> compiled fine, but when I try to run PD I get:
> 
> sh: 1: wish: not found
> 
> I've tried "sudo apt-get install tcl" but this didn't help.
> 
> It looks like others are having problems with Tcl applications as
> well: https://askubuntu.com/questions/1031632/tcl-tk-programs-fails-a
> fter-upgrade-to-18-04


wish is part of the tk package (which depends on tk8.6 on Ubuntu
18.04). So do:

  sudo apt install tk

and then try again.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] static array/text

[Roman Haefeli]

On Mon, 2018-05-07 at 00:02 +0200, Dan Wilcox wrote:
> Is there one way to define a "static" table or text data that can be
> shared among abstractions? I have a few abstractions which use lookup
> tables and I realize now that they are basically creating a copy with
> each instance when they could really share the same data directly. I
> suppose this would be somewhat related to [value].

Sounds like that this is such a common pattern that it would deserve a
built-in solution. 

In netpd, abstractions/instruments can call/create a [unpatch-singleton 
] whereas  is an arbitrary abstraction
holding a look-up table or similar that should be only instantiated
once. [unpatch-singleton] creates exactly one copy of 
and it creates it in a subpatch of  the unpatch instrument manager.
This way  persists for the whole session even if the
instrument that initially created it is closed.

https://github.com/reduzent/netpd

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Escaping/not resolving dollar argts in msgs/objects?

[Roman Haefeli]

On Tue, 2018-05-15 at 04:15 -0700, Derek Kwan wrote:
> Hello list,
> 
> Perhaps a bit of a long shot and pretty much the exact opposite of
> the $0
> in messages conversations as of late: Is there a way to NOT resolve
> dollar arguments in messages and/or objects?

I think you cannot dynamically disable the resolution of dollar
symbols.

> Example case: Lately for a project I've wanted to create vast swaths
> of
> [array define]s and I've done so with dynamic patching. Since I want
> their bound symbols to be something like "$0-snd0", "$0-snd1"
> $0"-snd2"... "$0-snd50", I DON'T want dollar arguments (particularly
> the
> $0) to resolve to anything

Do I understand correctly that you want to be able to create those
objects containing literal '$0'?

You can "trick" Pd into creating a symbol that itself has a dollar
variable:

[0 (
|
[obj 20 20 array define $$1-snd0]
|
[s canvas]

> . Similarly, I store filepath + array symbol
> pairs in texts to do a big load at the beginning and for right now
> and
> can always add the $0-bit via passing that symbol through a
> [makefilename], but I'm wondering if I can pass $0s unresolved into a
> text without having to manually type it in via the popup window.

You could use the same trick.

> Of course I can always edit the patch in emacs/vim and do a
> search/replace, but I'm looking for an in-Pd solutions... Also for
> the
> array business I suppose I could do that via [clone], but that
> situation
> doesn't seem ideal either...

I was just wondering why I haven't ever experienced the same need for
literal dollar symbols in my patching career and realized that I never
save dynamically created stuff. I rather let the dynamic stuff be
created each time I load the patch. This way all dollar variables
resolve to the currently correct value and I never bothered to use
literal dollar signs in dynamic patching. Maybe I'm not fully
understanding your case, but I can't see how having dynamically
generated '$0' is useful in any way. Either you create all dynamic
stuff from scratch, then you can as well use the value of $0 or you're
saving stuff for later, but why do you need $0 then? Don't you rather
want something fixed/controllable, that evaluates to the same value on
each run?

Roman





signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Escaping/not resolving dollar argts in msgs/objects?

[Roman Haefeli]

On Tue, 2018-05-15 at 14:09 +0200, Christof Ressi wrote:
> > [obj 20 20 array define $$1-snd0]
> 
> this only works as long as you don't save and reopen the patch, where
> "$$1" will become "$\$1" (which is resolved to "$\\$1" instead of
> "\\$1").

I see. Thanks for pointing it out.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Data structures - delete specific scalar?

[Roman Haefeli]

Hey all

Following up a thread from 2011:
https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html

I would like to know whether it is impossible to delete a specific
scalar, by pointer. If so, why is that? Does it use a design that makes
it difficult to allow this? To my untrained eye there is no apparent
reason why it is possible by editing the GUI graphically/manually, but
not per message.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sat, 2018-05-19 at 00:02 +0200, Ingo Stock wrote:
> to my knowledge it is not possible to delete a single scalar.

Thanks for the confirmation. I'm also wondering whether this will
always be like this or if it would be a trivial feature to add.

> The method
> to get rid of a scalar is to clear the subpatch and recreate
> everything.

Yeah. It's not very elegant and gets expensive pretty quickly. I was
wondering about alternative strategies, like moving non-used scalars
out-of-the-way and later re-use them. It's cumbersome to implement, but
probably less drastic than the clear-all-and-rebuild method. My goal is
to build GUIs with ds that are fully functional without requiring
switching into edit mode. I'd be interested in hearing about similar
success (or failure) stories.

Roman



On 05/18/2018 11:36 PM, Roman Haefeli wrote:
> > Hey all
> > 
> > Following up a thread from 2011:
> > https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html
> > 
> > I would like to know whether it is impossible to delete a specific
> > scalar, by pointer. If so, why is that? Does it use a design that
> > makes
> > it difficult to allow this? To my untrained eye there is no
> > apparent
> > reason why it is possible by editing the GUI graphically/manually,
> > but
> > not per message.
> > 
> > Roman
> > 
> > 
> > 
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > istinfo/pd-list
> > 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> tinfo/pd-list

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sat, 2018-05-19 at 17:00 +0200, Ingo Stock wrote:
> On 05/19/2018 11:56 AM, Roman Haefeli wrote:
> > Yeah. It's not very elegant and gets expensive pretty quickly. I
> > was
> > wondering about alternative strategies, like moving non-used
> > scalars
> > out-of-the-way and later re-use them. It's cumbersome to implement,
> > but
> > probably less drastic than the clear-all-and-rebuild method. 
> 
> Can only answer to this: There are several methods to make scalars
> invisible. Anyhow, in my experience the method to clear the subpatch
> and
> recreate everything works quite well and is imho the clean approach
> to
> do it, as all the scalars are redrawn every frame any way.
> 
> There are other limits to the use of data structures. Depending on
> your
> computer, when you get above 800 scalars or so, the patch becomes
> laggy.

Thanks for your considerations. That is exactly the kind of info that I
was looking for. I don't share the experience with the limit of 800,
though, but this is presumably related to the computer/CPU.

> Consider the attached patch:

Nice and illustrative example patch.

>  On load 1050 scalars are created, which is
> already quite heavy on my computer. 

I'm not sure I understand correctly. Just having the patch open is
heavy on your box? Or interacting with it?

> Anyhow, deleting a scalar by
> clicking on it works fine, using the clear and redraw method.>>

It works fine for me, too. Then I measured the time it takes to redraw
different numbers of squares. It seems computation time is roughly
proportional to the number of redrawn objects (1: 0.08ms, 500: 3.9ms,
1000: 7.6ms). So there is a penalty of this method with larger numbers
of scalars.

> Hiding scalars by making them invisible doesn't help with the lagging
> problem. Therefore i would recommend the clear and redraw method any
> day. ;)

I don't experience any lags by making specific scalars invisible. It
takes 0.007ms to make a single scalar invisible within a subpatch of
1050 squares. See my modified version of your patch.

Roman





#N struct 1003-square float x float y float id float vis;
#N canvas 1 99 1107 655 12;
#N canvas 1 88 450 300 \$0-display 0;
#X scalar 1003-square 2 2 0 0 \;;
#X scalar 1003-square 14 2 1 0 \;;
#X scalar 1003-square 26 2 2 0 \;;
#X scalar 1003-square 38 2 3 0 \;;
#X scalar 1003-square 50 2 4 0 \;;
#X scalar 1003-square 62 2 5 0 \;;
#X scalar 1003-square 74 2 6 0 \;;
#X scalar 1003-square 86 2 7 0 \;;
#X scalar 1003-square 98 2 8 0 \;;
#X scalar 1003-square 110 2 9 0 \;;
#X scalar 1003-square 122 2 10 0 \;;
#X scalar 1003-square 134 2 11 0 \;;
#X scalar 1003-square 146 2 12 0 \;;
#X scalar 1003-square 158 2 13 0 \;;
#X scalar 1003-square 170 2 14 0 \;;
#X scalar 1003-square 182 2 15 0 \;;
#X scalar 1003-square 194 2 16 0 \;;
#X scalar 1003-square 206 2 17 0 \;;
#X scalar 1003-square 218 2 18 0 \;;
#X scalar 1003-square 230 2 19 0 \;;
#X scalar 1003-square 242 2 20 0 \;;
#X scalar 1003-square 254 2 21 0 \;;
#X scalar 1003-square 266 2 22 0 \;;
#X scalar 1003-square 278 2 23 0 \;;
#X scalar 1003-square 290 2 24 0 \;;
#X scalar 1003-square 302 2 25 0 \;;
#X scalar 1003-square 314 2 26 0 \;;
#X scalar 1003-square 326 2 27 0 \;;
#X scalar 1003-square 338 2 28 0 \;;
#X scalar 1003-square 350 2 29 0 \;;
#X scalar 1003-square 362 2 30 0 \;;
#X scalar 1003-square 374 2 31 0 \;;
#X scalar 1003-square 386 2 32 0 \;;
#X scalar 1003-square 398 2 33 0 \;;
#X scalar 1003-square 410 2 34 0 \;;
#X scalar 1003-square 2 14 35 0 \;;
#X scalar 1003-square 14 14 36 0 \;;
#X scalar 1003-square 26 14 37 0 \;;
#X scalar 1003-square 38 14 38 0 \;;
#X scalar 1003-square 50 14 39 0 \;;
#X scalar 1003-square 62 14 40 0 \;;
#X scalar 1003-square 74 14 41 0 \;;
#X scalar 1003-square 86 14 42 0 \;;
#X scalar 1003-square 98 14 43 0 \;;
#X scalar 1003-square 110 14 44 0 \;;
#X scalar 1003-square 122 14 45 0 \;;
#X scalar 1003-square 134 14 46 0 \;;
#X scalar 1003-square 146 14 47 0 \;;
#X scalar 1003-square 158 14 48 0 \;;
#X scalar 1003-square 170 14 49 0 \;;
#X scalar 1003-square 182 14 50 0 \;;
#X scalar 1003-square 194 14 51 0 \;;
#X scalar 1003-square 206 14 52 0 \;;
#X scalar 1003-square 218 14 53 0 \;;
#X scalar 1003-square 230 14 54 0 \;;
#X scalar 1003-square 242 14 55 0 \;;
#X scalar 1003-square 254 14 56 0 \;;
#X scalar 1003-square 266 14 57 0 \;;
#X scalar 1003-square 278 14 58 0 \;;
#X scalar 1003-square 290 14 59 0 \;;
#X scalar 1003-square 302 14 60 0 \;;
#X scalar 1003-square 314 14 61 0 \;;
#X scalar 1003-square 326 14 62 0 \;;
#X scalar 1003-square 338 14 63 0 \;;
#X scalar 1003-square 350 14 64 0 \;;
#X scalar 1003-square 362 14 65 0 \;;
#X scalar 1003-square 374 14 66 0 \;;
#X scalar 1003-square 386 14 67 0 \;;
#X scalar 1003-square 398 14 68 0 \;;
#X scalar 1003-square 410 14 69 0 \;;
#X scalar 1003-square 2 26 70 0 \;;
#X scalar 1003-square 14 26 71 0 \;;
#X

Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sun, 2018-05-20 at 05:40 -0700, Derek Kwan wrote:
> Roman Haefeli  writes:
> 
> > Hey all
> > 
> > Following up a thread from 2011:
> > https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html

> If I'm not mistaken, this relates to a thread I started in Jan 2017
> and
> I think this bit from Christof Ressi might prove releavant to these
> discussions so hopefully this link could help with the current
> discussion:
> 
> https://lists.puredata.info/pipermail/pd-list/2017-01/117295.html

Oh yes. I didn't find this one when using search machines. This
basically answers my questions. Thanks.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sun, 2018-05-20 at 15:31 +0200, Christof Ressi wrote:
> this has been on my wish list for a while and I want to do a PR. do
> you guys have suggestions which kind of interface you would prefer?
> these come to my mind:
> * [delete] object: send it a pointer and it will delete the scalar

I thought this one to be the most natural, since there is also an
[append] object.

> * [delete ( message for canvases

There are no other uses where  a method uses a pointer as argument, are
there?

> * [delete( message for [pointer]: deletes the scalar of the currently
> stored pointer.

Sounds good, too, and seems what has the most thumb-ups yet.

> I tend towards the last option, since [pointer] is already used to
> traverse a subpatch, so [delete( could go well with [traverse(,
> [bang( and [next(. the canvas messages would also makes sense to me.
> having a dedicated object seems rather overkill.

You're probably right.


Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Trigger/Gate

[Roman Haefeli]

Hi Rainer

On Fri, 2018-05-25 at 18:55 +0200, Rabbit ́s . wrote:
> Hi there,
> 
> I´m doing a sequencer in pd for my modular rig starting with a
> trigger/gate abstraction that should bang the analog envelopes &
> friends. A very simple approach starting as trigger and ends up in
> variable gatelenghts - see patch attached.
> 
> If I bang it manually there is no problem. If I bang it with a metro,
> the gate starts to wiggle a bit in lenght.
> 
> Hmmm, guess there is a sync problem with free running metro and
> dac~???

Not really. The [line~ ] object starts (and ends, I guess) ramps only
on block boundaries, while the [metro] sends bangs with exact time
periods, and so does [delay]. It happens that the bang arrives
sometimes at the start of the block, sometimes at the end, the same
with the bang from [delay]. So the number of full blocks that fit
between the metro bang and the delay bang varies by one block. 

The reason why you don't see that jumping when manually triggering the
gate is that GUI interventions are quantized to blocks (or even more
coarsely). 

If you want to have a (sub)sample-precise envelope, you need to use
[vline~] which is able to generate ramps starting and ending at any
time, even in between samples. Simply replace [line~] with [vline~] in
your patch. You will notice that not the length of the envelope is
wiggling now, but the position. This is due to [tabwrite~] being able
to start writing to a table only at block boundaries, too.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [soundfiler] - get rid of the arbitrary default value for "-maxsize"

[Roman Haefeli]

On Sat, 2018-05-26 at 16:37 +0200, Christof Ressi wrote:
> https://github.com/pure-data/pure-data/pull/366
> 
> I guess that arbitrary 16MB default maxsize is a relict of past
> times... let's get rid of it :-)

You make it sound like the reason for the limit was precious memory. I
agree that memory often is not that precious anymore, but the real
reason for this limit might have been the fact that you lose precision
the higher your index for table lookup is. I guess above 16MB you even
can't address every single integer anymore with 32bit float numbers.
You kinda need to know what you do when exceeding that or the result
may have bad sound quality.  

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Random

[Roman Haefeli]

On Wed, 2018-05-30 at 11:30 -0300, José de Abreu wrote:
> if you can use adc~ (assuming that your mic can capture some noise)
> you can sum some snapshots~ with high gain and then voilà, random
> number each time

Attached is a method that doesn't require audio to be on (and thus also
no real adc~). 

Roman#N canvas 9 110 450 300 10;
#X obj 63 206 until;
#X msg 63 229 281.29;
#X obj 63 252 pow 392.1;
#X obj 44 49 t b b b;
#X obj 83 83 realtime;
#X obj 44 21 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1
-1;
#X msg 63 183 2;
#X obj 83 106 * 1000;
#X obj 83 129 int;
#X floatatom 83 152 10 0 0 0 - - -, f 10;
#X text 150 152 seed;
#X connect 0 0 1 0;
#X connect 1 0 2 0;
#X connect 3 0 4 1;
#X connect 3 1 6 0;
#X connect 3 2 4 0;
#X connect 4 0 7 0;
#X connect 5 0 3 0;
#X connect 6 0 0 0;
#X connect 7 0 8 0;
#X connect 8 0 9 0;


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] intelligent patching

[Roman Haefeli]

Hi IOhannes

I think those additions are immensely useful. Thanks a lot for porting
them and thanks to Jonathan and Ivica for implementing them (I hope I
thanked all persons involved, and would like to include those that I
didn't know about).


On Wed, 2018-06-06 at 15:37 +0200, IOhannes m zmoelnig wrote:
> new connection features:
> 
> - select any two objects, and press + (or + if you
> insist), to connect them (trivially, so just the first iolet)

Cool.  A shortcut is often quicker than finding the right spot with the
mouse.


> - to connect a (signal) outlet to multiple arbitrary inlets, you can
> now
> press  while hovering the yet-unconnected cord over an inlet

> - to add more connections between two already connected object,
> select
> the connection and pressl + to extend the connections to the
> right ("duplicate")


> - to fully connect two objects, *select* both objects before
> connecting
> them.

Also very nice. Though it's odd that you can employ a shortcut when
creating a single connection, but you need to manually make the
connection when the end result should be many connections. Can shortcut
and multiple connections be combined somehow? 

> - to connect multiple objects to a single inlet, select all the
> source
> objects (but not the sink object) before connecting them.

Hm... now this makes my above point mute, since obviously for -k
to work you need to select both ends. But I like how you can do
different things with different kinds of selections. So maybe combining
  multi-connect with shortcut is not such good idea after all. 

>   - (the other way round works as well, but will give you fan-
> outs!!!)
> - to connect multiple objects to a multi-inlet object, select all the
> source objects *and* the sink object before connecting the leftmost
> source to the leftmost inlet.
> - to connect a multi-outlet object to multiple objects, select all
> the
> source object *and* all the sink objects before connecting the
> leftmost
> outlet to the leftmost sink.

I noticed that -z only removes the manually created link when
creating many links simultaneously. Definitely not a serious issue, but
still deserves to be mentioned.

I truly hope this makes it into Pd. My local Pd will have it built-in
as long as it doesn't break. This improves my patching  work-flow
dramatically while having (almost) no side effect (the one I can think
of is spending a shortcut, which is certainly well spent).  

This feature request is only loosely related: Call me an OCD patient,
but I spend quite some time on getting all the patch chords straight.
This would be so much easier if objects would snap into an invisible
grid of 10x10 pixels. When not creating GUIs, there is no point in
placing objects at pixel-exact positions. Ideally, snap-to-grid could
be turned on and off by shortcut or menu. 


Roman





signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Tue, 2018-06-12 at 16:16 -0300, Alexandre Torres Porres wrote:

> Well, there has definitely been results in the design of Pd that came
> out of recent discussions. Let me point again to what Miller said in 
> https://lists.puredata.info/pipermail/pd-list/2017-07/119839.html to
> highlight the notion that we should not use "Standard Path" to
> install externals, and this is regardless if there is one or more of
> them, and if there should be only one... it doesn't matter, just
> don't use them. 

I seem to disagree in almost everything you say.

I tell people to do exactly the opposite of what you're telling them.
Your proposal has two - imho: major - drawbacks. By putting libraries
anywhere (outside any searchpath) and loading them per preferences, you
loose the ability to 'activate' libraries on the fly from the patch
with [declare] since they are already loaded anyway.  By doing it this
way, you require the user to modify their environment in order for them
to run a certain patch. In my understanding of programming
environments, the software imports/declares its own dependencies. The
dependencies need to be installed, but the actual loading happens from
within the software. I guess that is common quite common practice. I
don't see a good reason to proactively work against this as you seem to
do. In my understanding, the user should just know what libraries to
download and the rest is done by the patch by using the right
[declare}s. Also, by preventing [declare] from working - as you propose
- how is a patch dev supposed to document the patch's dependencies?
What you suggest just simply doesn't add up for me.  


> As Miller said in that message, we should just use the "Path"
> mechanism, and no Standard Paths. This means just have your externals
> anywhere and put them in "Preferences => Path" if you want them to be
> automatically loaded. Now, this may not yet be 100% fully well
> integrated with Pd, I don't know what IOhannes meant by that, but I
> can say that if you want to use [declare] instead of doing this, it
> won't work well, but there's already a Pull Request that fixes it. So
> whatever is not perfect yet with the new system should be fixed soon.
>  
> > there's a deep rift between the factions.
> 
> Ok, I don't know about that

Now you know. 

>  and I haven't seen one. By the way, let me just make it clear that I
> do not have a dog in this fight, I'm just going with the flow without
> disputing anything. Yeah, I actually first opposed to the new way of
> doing things since 0.48, 

By 'new way' you mean that libraries should be installed anywhere and
added to the preferences? It appears to me that you created this mess
by requesting that  ~/Library/Pd should be replaced by ~/Documents/Pd
(in macOS, at least). Now, Deken asks to create this folder that is of
no practical use. This proposal probably got triggered by the fact that
Apple decided to hide ~/Library from Finder. I couldn't care less about
macOS  , but in my opinion the fact that you need to hit Shift-Cmd-G to
graphically visit this folder doesn't warrant this change in Pd. Yeah,
it was stupid move by Apple, but shouldn't every macOS user know how to
visit invisible folders anyway? Does the Pd community have to care
about that? Why does the user need to check that folder anyway, since
Deken already manages it quite well? Now there is a new folder which is
not a standard path and just creates mess and confusion and pages long
discussions in github issues and - sorry for saying it directly - which
 you are at least partially responsible for. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

Hey Dan

Thanks for trying to explain.

On Thu, 2018-06-14 at 01:18 +0200, Dan Wilcox wrote:
> There seems to be a bit of FUD in this "discussion."

Maybe things aren't that bad as they were presented. For my part, I
lost track of who favors what kind of design.

> Some things from my perspective:
> 
> 1. Pd's library/path mechanism is largely oriented toward *local*
> libs first and *global* ones later, ie. download externals to
> individual project (sub)folders.

Pd already used to work like that for quite a while, no?

> I believe the centralized loading was added later on in Pd-extended. 

I don't understand what you mean by that. Pd-extended already pre-
loaded a subset of the installed externals (do you mean this?), which -
imho - was a bad design choice. It meant there was one person deciding
what comes pre-loaded and what not.

> If we follow the "programming language model", this might be similar
> to installing a Python egg locally or globally. I don't see how
> supporting both modes of working is a problem.

Me neither.

> 2. IOhannes convinced me, over time, that the "stdpath" loading
> mechanism used by the "extra" folder is problematic as it adds too
> many (sub) search paths by default and it becomes harder to
> tell/control what's being loaded.

Forgive my ignorance, but I don't understand. Does Pd now look into
extra's subfolders? Currently I still have to actively load stuff with
[declare -stdlib] or [declare -stdpath]. 

>  The "better way" is for people to specify those externals paths
> directly, either with the user search paths and/or declare.
>  There is much less ambiguity as to what's going on at the loss of
> "just put things in this place" ease.

So paths added by the users will be searched by deken? So  instead of
specifying paths to the library root - as we currently do it - adding a
path in the future means adding a searchpath that is container for many
libraries? And deken will find libraries inside the newly added
searchpath root? 

> 3. As suggested by Alexandre, I wrote a PR to help address how
> declare search when using -path & -lib by having them search along
> user search paths as well: https://github.com/pure-data/pure-
> data/pull/205. I feel this is a much closer method of using declare
> to how other programming languages handle such things, ie. Lua's
> require.

OK, I hopefully understand now. Am I right in thinking that declare's
-stdlib, -stdpath flags are considered superfluous because -lib and
-path will scan all searchpaths in a local -> global order, including
the parent patch's folder?

> 4. The Pd Documents path (aka ~/Documents/Pd) is simply a helper
> location for beginners. It is only a regular user search path
> added by default (when desired) and does not search subfolders. 

Now you challenge my understanding of the term searchpath again. I
thought the new idea is that you will be able to load libraries with
[declare] from user-added searchpaths? What's the point of creating
that folder then? 

> Nobody has to use it and it can be disabled at any time.

My beef with it is that - the way it is presented to me -  it suggests
to do things that create confusion later. 

As a new user:

"Do you want to create ~/Documents/Pd"

Yes

"Do you want to add it to the searchpaths?"

Yes

When downloading stuff with deken: "Do you want to install 'mylib' to
~/Documents/Pd?"

Yes

Now, I'm going to load mylib with [declare -{std}path mylib] in my
patch which fails.

What am I missing here?


> 5. Yes, the macOS hiding the ~/Library folder is problematic for many
> users as they don't know how to show it and are afraid to modify
> things within it. I've recently taught classes to beginners that are
> just learn gin the concept of a "file system" as they grew up mainly
> using "mobile phones"

I don't see how deken requires users to have a notion about a
filesystem. Ideally, I'd use deken to tell _what_ I want to install.
Ideally, I'd tell my patch through [declare] _what_ to load. All the
_where_ stuff shouldn't be a question neither at installing nor loading
time. The _where_ stuff should only matter when the user tweaks their
environment: "I'd rather put my 4.5 TB of Pd externals on my external
drive ". 

>  ... Plus, ~/Library/Pd was also a "kitchen sink" std path with the
> issues listed in #2.
> 
> 6. I've attempted to provide some solutions to various issues
> outlined over the last year regarding [declare] and folders. It would
> be helpful to get more feedback earlier on in testing /
> experimentation, rather well after a release. 

Valid and important point. I will try to the get a more clear picture
from the actual implementation instead of a messy Pd list thread.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Thu, 2018-06-14 at 14:18 -0300, Alexandre Torres Porres wrote:
> > Now, I'm going to load mylib with [declare -{std}path mylib] in my
> > patch which fails. What am I missing here?
> 
> Yes, there's the declare issue we know and are addressing, but I'd
> also like to highlight that Deken also asks if you want to add what
> you downloaded to the search path. This intentionally provided a
> working solution to this issue at the time of the release, making it
> all just work by clicking "yes" to stuff, which is quite fine for
> newcomers.  

OK. Just to be sure we are on the same page, I understand that the
following assumptions will be true, once the PRs are accepted:

 * The user defines the environment. The user can define in the pre-
   ferences in which paths [declare] looks for libraries.

 * Patches can use [declare] to load libraries, regardless where they
   are installed as long as the install path was added as searchpath
   in the preferences

 * Patches don't need to know anything about the environment.


Example:


User adds '/home/jane/fanypdcollection/' to the paths in Pd's
preferences. Then she installs iemnet to
/home/jane/fancypdcollection/iemnet after she configured Deken to
install libraries to /home/jane/fanypdcollection/. Then she creates a
new patch, therein a [declare -path iemnet] and a [tcpclient] and the
latter creates successfully.

Is this the idea?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] Release of tpf-client / tpf-server

[Roman Haefeli]

Hey all

Let me a announce a by product that was created while working in a
research group exploring formats for telematic performances.

tpf-client[1] is a graphical multi-instance jacktrip clone built in
Pure Data. It establishes low-latency multi-channel audio connections
between two or more endpoints. Unlike the traditional jacktrip utility,
it doesn't require any of the endpoints to have public IP address, a
requirement that is hard to fulfill in many concert venues.

The client connects to a server - the tpf-server[2] - that keeps track
of connected clients and lets client agree on common parameters like
samplerate and blocksize. The server acts as a UDP proxy between
clients and thus allows clients to send audio among each other even
when they are behind firewalls. Alternatively, clients may establish a
direct peer-to-peer connection by using a technique called UDP hole
punching. This feature is still considered experimental and may not
work in certain network environments.

We have been successfully using this setup in a number of concerts with
two or three concert venues and the additional latency due to the UDP
proxy was small enough for our purposes, since we run the server close
to our university. The client comes pre-configured to use our server
running at telematic.zhdk.ch. However, we advise other interested
groups to set up their own server for productive use, on the one hand
to keep latency as small as possible, on the other hand we're still
doing experiments and might restart or adapt services. If groups or
institutions are interested to use this setup, we would appreciate to
get some feedback. Contact me directly.

The client:
[1] https://gitlab.zhdk.ch/TPF/tpf-client
Standalone-App for macOS: 
https://gitlab.zhdk.ch/TPF/tpf-client/tags/v1.0.0

The server:
[2] https://gitlab.zhdk.ch/TPF/tpf-server


Thank you,
Roman


signature.asc
Description: This is a digitally signed message part
___
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

Re: [PD] Glitch

[Roman Haefeli]

On Wed, 2018-07-04 at 10:53 +0200, michael strohmann wrote:
> 
> Hello!
> from time to time my patch produces this beautiful, but unwanted
> glitch. (audiofile attached)

Sounds like I'm doing doing music. I wouldn't know how to identify the
glitch aspect of it. How does it sound without the glitch?

Some suggestions to make such things a bit easier:
 * Do not use compressed files to illustrate a glitch. It's hard to
   know what to attribute to the compression and what to the glitch.
 * If possible, provide also an example of how it is supposed to sound.
 * If possible, rather post links to your media files instead of
   attaching them to your mail. There is no point in every list member
   have their mail account filled with media files.

> are there any ideas what could cause this behaviour?

I would first figure out where the glitch happens. Is Pd actually
generating this sound or is Pd's audio playback glitchy? You can figure
this out by doing a recording from within Pd with [writesf~]. If the
result sounds OK, then you know that the glitch happens somewhere
between Pd and the sound card. If the result is glitchy, then the
glitch happens already within Pd, for instance because some object or
your patch is buggy. 

> i am running this on a RPi B+, using sfplay~ to playback a 4 Channel
> Audiofile.

Why are you using [sfplay~] and not the built-in [readsf~]? Does the
glitch still appear when using [readsf~]?

> the playback is triggered via a sensor/GPIO or via OSC.

This hopefully doesn't matter.

> restarting the RPi eliminates the glitch.

Could be some sound card issue, but check the other things first.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] comments in [text]

[Roman Haefeli]

On Thu, 2018-07-12 at 10:34 +0200, Martin Hiendl wrote:

> I was wondering whether there is a comment function for the [text]
> object that I'm not aware of, or if not, whether that would be a
> useful feature (for handling and navigating large cue-lists for
> example).


How about this:

Mark your comments with a '# '-prefix (mind the space). When parsing
the content of [text], make sure to pipe everything to [route #] and
consider only the right outlet of [route #]. There you go!

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] iemlib fails to load SOME objects OSX 10.10

[Roman Haefeli]

On Fri, 2018-07-13 at 11:37 +0200, IOhannes m zmölnig wrote:
>  (since 1.21, the objects are now
> included in a single binary "iemlib.pd_darwin", so you need to load
> that
> instead of the traditional iemlib1 resp. iemlib2)

That sounds like some progress. I only see a package for Windows in
Deken. Are there plans to upload packages for other platforms? 

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Thu, 2018-06-14 at 16:32 -0300, Alexandre Torres Porres wrote:
> 2018-06-14 15:35 GMT-03:00 Roman Haefeli :
> > Is this the idea?
> 
> Yes! And it's working like that in my tests.

Ok, it's working for me, too. I see significant progress in that (after
having cleared all preferences) I end up with a "working" setup by
clicking myself through the defaults. Things get downloaded to
~/Documents/Pd/externals, which was automatically created added to the
search paths. After installing externals through 'Find externals', I
can load them by [declare -lib ] and [declare -path ].

So, does that mean the [declare]-flags -stdlib and -stdpath are
obsolete now?

I can't spot any problems with the branch feature/declare-path, but
virtually all of my patches are broken with it because of incompatible
[declare] flags. I like the 'new way' much better, but I wonder what is
a good path to get there. It's actually an easy thing to replace all
occurences of -stdlib/-stdpath with -lib/path. But switching behaviour
from one version of Pd to the next seems bold.

Roman






signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] standard paths for externals

[Roman Haefeli]

On Fri, 2018-07-13 at 14:27 -0300, Alexandre Torres Porres wrote:
> 
> 
> 2018-07-13 11:12 GMT-03:00 Roman Haefeli :
> > So, does that mean the [declare]-flags -stdlib and -stdpath are
> > obsolete now?

Oops, bad wording on my part. I should have said 'in the declare-path
branch' instead of 'now' as readers might think it was already changed
in Pd, which is _not_ the case. I'm talking about a feature branch that
  possibly/hopefully makes it into Pd. 

> yes, and this was mentioned in this thread already - but it is kept
> there for backwards compatibility concerns, for not to have a change
> in behaviour from one version to another, so your old configuration
> still works 

Alright, that's absolutely correct. Old flags still work with old
layout, new flags work with new layout. So there is no problem with the
transition. Thanks for the clarification. 

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] [else/dir] leaks file handles (was: "too many open files" error in 0.48.1)

[Roman Haefeli]

Hey all

Not only by creating 1020 instances of [else/dir] you can crash Pd, but
also by sending it a 337 'reset, open .' messages. I guess the reason
is the same: [else/dir] is leaking file handles. 

It appears I tried  [else/dir] for the similar reasons as you, Liam. I
am also using [ggee/getdir] and [moocow/readdir] now and thought about
reducing dependencies by switching to else. It turns out I can't switch
yet.

Roman



On Sun, 2018-05-27 at 19:26 +, Liam Goodacre wrote:
> OK, I've just spent several hours on this, testing upwards of 200,000
> parallel abstractions and crashing my computer almost as many times.
> But I managed to figure it out.
> 
> (Most of) you will be relieved to hear that the problem does not
> originate with the PD core, but with externals, as IOhannes
> suggested. Alex will not be relieved to hear that the culprit is
> [else/dir]. It seems that the 1019th instance of this object crashes
> PD! How strange.
> 
> I'm filing a bug report on git and moving on with my life.
> 
> Liam
> 
> 
> From: Pd-list  on behalf of Liam
> Goodacre 
> Sent: 22 May 2018 05:36
> To: pd-list@lists.iem.at
> Subject: Re: [PD] "too many open files" error in 0.48.1
>  
> Thank you for the input. It will be a few days before I can do any
> serious testing, but I can answer some of your questions now.
> 
> IOhannes: yes, I upgraded PD, my externals, and my OS, all at the
> same time. I'll try it out with various different versions of the
> same and let you know what happens. But just as a heads-up, it's
> quite possible that I am trying to load more than 10,000 abstractions
> at once. Quite difficult to count them though!
> 
> If neither the externals nor the OS turn out to be the problem,
> I'll try to come up with a simple test case and get back to you.
> From: Pd-list  on behalf of IOhannes m
> zmölnig 
> Sent: 21 May 2018 20:50
> To: pd-list@lists.iem.at
> Subject: Re: [PD] "too many open files" error in 0.48.1
>  
> On 05/21/2018 09:37 PM, ub@xdv wrote:
> > On 21.05.2018 20:54, Claude Heiland-Allen wrote:
> >>
> >>
> >> On 21/05/18 19:35, ub@xdv wrote:
> >>> hello,
> >>>
> >>> On 20.05.2018 06:50, Liam Goodacre wrote:
>  In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD
> refuses to
>  open patches or create any more abstractions for me. I get an
> error
>  message saying "too many open files". Granted I have a lot open,
> but
>  this is a serious problem as it means I can't access all of my
> old
>  performances. They worked fine in 0.47.
> 
>  Any ideas?
> >>> this is not really a problem with pd
> >>
> >> I disagree. The most common cause of "too many open files" is a
> bug in
> >> closing files properly, 
> 
> intuitively i would agree.
> 
> > possible. never occured to me. is it in the issue tracker?
> 
> no (afaik). it hasn't been reported before.
> 
> > 
> >> because 1024 simultaneously-open files should be
> >> enough for most use cases.definitely, but when someone says
> "Granted I have a lot open", that
> > could be an understatement. or a regression of some sort.
> 
> so i did a test run, with some heavily embedded abstraction, that is
> loaded a total of 1 times.
> $ ulimit -Sn
> 1024
> $ valgrind --track-fds=yes pd -noprefs -oss -nosound -nomidi -nrt
> -stderr -open test.pd
> [...]
> ==29030== FILE DESCRIPTORS: 3 open at exit.
> ==29030== Open file descriptor 2: /dev/pts/12
> ==29030==
> ==29030==
> ==29030== Open file descriptor 1: /dev/pts/12
> ==29030==
> ==29030==
> ==29030== Open file descriptor 0: /dev/pts/12
> ==29030==
> ==29030==
> [...]
> $
> 
> so there seems to be neither a temporary file-handle leak (because my
> 1 abstractions load just fine) nor an absolute file-handle leak
> (since the only handles that are left open by the program are stdin,
> stdout, stderr)
> 
> 
> so i guess there must be something wrong with the patch.
> 
> @liam are there any externals in use? did you upgrade the entire
> system
> or just Pd? when using an older version of Pd, does the problem
> persist?
> 
> gfmtdsar
> IOhannes
> 
> 
> > 
> > 
> >>
> >>
> >> Claude
> >>
> >>> , but with your shell- or system
> >>> configuration limiting the number of open file descriptors.
> >>>
> >>> check your current shell-limit with
> >>> ulimit -Sn
> >>> -S is for soft limit (you can lower, but not raise, the hard
> limit).
> >>> raise the limit in your shell with
> >>> ulimit -n 65536
> >>> start pd from that shell and see if the situation improves.
> >>>
> >>> if that doesn't help, you can check the kernel limits with
> >>> cat /proc/sys/fs/file-nr
> >>> which returns 3 numbers, the first of which is the number of open
> files,
> >>> the last of which is the limit.
> >>>
> >>> increase the value of "nofile" in  /etc/security/limits.conf
> >>> do
> >>> sudo sysctl -p
> >>>
> >>> additional steps are required to make these settings permanent,
> the
> >>> ulimit -n 65536 would have to go into your .bashrc so it's
> executed at
> >>> system startup.

Re: [PD] [else/dir] leaks file handles (was: "too many open files" error in 0.48.1)

[Roman Haefeli]

Hey Alex

On Tue, 2018-07-24 at 12:44 -0300, Alexandre Torres Porres wrote:
> Sorry, I thought I had fixed this in the last update. I swear it was
> working for me, but then... that reported bug came back :) 

No need to be sorry. I'm not complaining, but simply reporting. 

> The object still works fine for me in my use cases. 

I figured it is still easy for me to work-around the problem (actually,
I don't need to open the same two directories again and again, I could
just use two instances of [dir] and open each of those directories
once). However, stuff like that surely is going to bite you back in the
future. It's certainly better to fix it anyway regardless of any
specific use case.

> Anyway, I'll give it another go in the next update. If I fail
> miserably I'll ask for help.

I don't know if it works the same on macOS, but on Linux I can check
what is going on with the lsof command, specifically 'lsof -c pd' which
lists all files openend by processes named pd. Each time I send 'open
/home/roman/Downloads' to [dir], I see two additional lines in lsof's
output:

pd  9120 roman   23r   DIR0,5428672 29098010 /home/roman/Downloads
pd  9120 roman   24r   DIR0,5428672 29098010 /home/roman/Downloads

>  I just have other plans for the moment though...

Sure. Thanks for the library anyway.

Roman 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [else/dir] leaks file handles (was: "too many open files" error in 0.48.1)

[Roman Haefeli]

On Tue, 2018-07-24 at 12:44 -0300, Alexandre Torres Porres wrote:
> Sorry, I thought I had fixed this in the last update. I swear it was
> working for me, but then... that reported bug came back :) The object
> still works fine for me in my use cases. Anyway, I'll give it another
> go in the next update.

My understanding is that calling opendir() opens a file descriptor that
is only closed after calling closedir() on that file descriptor. As far
as I can see, [dir] never calls closedir() and thus it accumulates open
file descriptors. So, I guess what you need to do is to close the
current file descriptor each time before processing 'reset' or 'open'
methods which I believe are the two methods that call opendir().

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] table reverse lookup

[Roman Haefeli]

Hi

I'm using a couple of same-size tables to store tuples of numbers so
that their index is there ID. When (tab)reading all tables at the given
index, I get back the hole tuple. Mostly I have an ID and I need to
look up some value which is obviously an inexpensive task.

But sometimes I know two values (the combination of the two values is
unique) and I need to find the corresponding ID (index where both
values are found in their respective tables). I'm currently doing a
reverse lookup by scanning the table(s) which is more expensive than
the forward lookup. 

Let's assume memory usage is less of a concern, is there an
complementary way to store the data (x tuples of same size) that allows
for a quick reverse lookup? 

ID -> (x, y): easy

(x, y) -> ID: ??

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] feature request: [array search]

[Roman Haefeli]

Hi again

While we are at it: Wouldn't an [array search] be an immensely useful
object?

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

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

[Roman Haefeli]

On Tue, 2018-09-04 at 17:29 -0400, Martin Peach wrote:
> 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?

Yes, absolutely. Thanks for mentioning.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] table reverse lookup

[Roman Haefeli]

Hi William

On Tue, 2018-09-04 at 19:51 -0400, William Brent wrote:
> The "equals" method of [tabletool] returns the indices of a value
> you're searching for, as well as the number of occurrences. 

Thanks. That's quite a cool external and definitely covers what I need.

I'm still curious, though, if it's possible to implement a lookup and
reverse lookup in a way that does not require a scan. 

Roman

> On Tue, Sep 4, 2018, 5:19 PM Roman Haefeli 
> wrote:
> > Hi
> > 
> > I'm using a couple of same-size tables to store tuples of numbers
> > so
> > that their index is there ID. When (tab)reading all tables at the
> > given
> > index, I get back the hole tuple. Mostly I have an ID and I need to
> > look up some value which is obviously an inexpensive task.
> > 
> > But sometimes I know two values (the combination of the two values
> > is
> > unique) and I need to find the corresponding ID (index where both
> > values are found in their respective tables). I'm currently doing a
> > reverse lookup by scanning the table(s) which is more expensive
> > than
> > the forward lookup. 
> > 
> > Let's assume memory usage is less of a concern, is there an
> > complementary way to store the data (x tuples of same size) that
> > allows
> > for a quick reverse lookup? 
> > 
> > ID -> (x, y): easy
> > 
> > (x, y) -> ID: ??
> > 
> > Roman
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/l
> > istinfo/pd-list

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] type size of a commentary

[Roman Haefeli]

On Fri, 2018-09-21 at 16:37 +, Liam Goodacre wrote:
> There are 3 options that I can think of:
> 
>  1. Use regular comments and change the font size in the Edit menu  
> (but this will change the text size of all objects as well).

 1a. Use regular comment inside a GOP'd abstraction where you can
 freely adjust the font size independent of the font size of the
 parent patch. Apparently, this is cumbersome, but still possible.

Romna

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple instances of a patch forbidden in 0.49, why?

[Roman Haefeli]

On Sat, 2018-09-22 at 23:11 +0200, Christof Ressi wrote:

> OTOH, I kind of agree with the others that I never thought it was a
> problem that you can open the same patch several times...

Me neither. I do think it should be allowed one way or the other.
Having to use a flag for it (probably the least annoying option) is
still slightly annoying.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Unnecessary scrollbars since 0.49

[Roman Haefeli]

Hi

It seems there is a slight regression in the logic that decides whether
to show the scrollbars or not. According to my experience, the
behaviour in 0.48 was quite good and now sometimes when opening a
canvas, scrollbars are drawn when none are needed, even for empty
windows. When editing the patch (for instance: by creating an object)
they immediately disappear. 
Another less nice side effect: When the canvas size is chosen so that
objects fit tightly in with only little white space, the scrollbars
cover some objects and justify their existence by appearing at all. To
get rid of them one has to resize the window by first increasing it
enough just to decrease it again.

It does not happen every time with every canvas, but it does happen.

Roman 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] multiple instances of a patch forbidden in 0.49, why?

[Roman Haefeli]

On Sat, 2018-09-22 at 23:29 +0200, Antoine Rousseau wrote:
> Of course [once] would be much better than [lock]

[once] is taken by iemlib. Not that I think every library in existence
should be considered regarding name conflicts when introducing new
objects to Pd, but I feel that [once] is in wide use and adding a
[once] with totally different behavior would be a bold move.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] moving windows in 0.49

[Roman Haefeli]

Hi

Another regression I just observed: When sending 'vis 0, vis 1' to a
canvas repeatedly, the window keeps moving to the top left of the
screen. The offset is only a few pixels in each dimension. . I observe
this with 0.49test3 (updated and compiled just now) on Ubuntu 18.04
(Gnome). This happens regardless of the menu wrapping of narrow
windows. I checked again and it does not happen in 0.48 in different
environments (Ubuntu 16.04 / Fluxbox, Ubuntu 18.04 / Gnome, Windows
10). 

I wonder whether this is related to the recent 'Window Title Bar off
screen' thread: What if the offset is exceptionally large there for
some reason? I haven't thoroughly checked, but the help files don't use
negative canvas positions.

Roman
 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Unnecessary scrollbars since 0.49

[Roman Haefeli]

On Sun, 2018-09-23 at 00:06 +0200, Dan Wilcox wrote:
> *sigh* This is really a constant battle. I added a rather
> overcomplicated method to fix this in 0.48 and found a much simpler
> way to do it later on, or so I thought. The problem always comes down
> to the scrollbar logic being triggered when the window is the wrong
> size while it's still opening.
> 
> As for the resizing part, I really could never figure that out. You
> are WELCOME to try.

I hear you. I imagine this is not trivial.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Some patches broken in 0.49test3

[Roman Haefeli]

Hi

Sorry, need to report something probably more serious. Some of my
patches trigger messages like the following:


(Tcl) INVALID COMMAND NAME: invalid command name ".x558795b0c400.c"
while executing
".x558795b0c400.c itemconfigure 558795b682c0LABEL -font {{DejaVu Sans Mono} -11 
bold}"
("uplevel" body line 10)
invoked from within
"uplevel #0 $docmds"


Side effects are that sometimes the label of [cnv] is not updated. Or
the canvas stays blank after dynamically creating stuff and objects are
only shown after closing the window and opening it again. 

I don't have a small patch yet that triggers the problem, but will try
to figure one out.

BTW.: this is with  0ee284ecfb5215

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Some patches broken in 0.49test3

[Roman Haefeli]

Hey Claude

It seems you already did the hard work. Sorry for not having checked
more carefully. I'm glad attention is already paid to the issue.

Roman

On Sat, 2018-09-22 at 23:29 +0100, Claude Heiland-Allen wrote:
> Hi Roman,
> 
> On 22/09/18 23:19, Roman Haefeli wrote:
> > Hi
> > 
> > Sorry, need to report something probably more serious. Some of my
> > patches trigger messages like the following:
> > 
> > 
> > (Tcl) INVALID COMMAND NAME: invalid command name ".x558795b0c400.c"
> >  while executing
> > ".x558795b0c400.c itemconfigure 558795b682c0LABEL -font {{DejaVu
> > Sans Mono} -11 bold}"
> >  ("uplevel" body line 10)
> >  invoked from within
> > "uplevel #0 $docmds"
> > 
> > 
> > Side effects are that sometimes the label of [cnv] is not updated.
> > Or
> > the canvas stays blank after dynamically creating stuff and objects
> > are
> > only shown after closing the window and opening it again.
> 
> You might try my (unfortunately too slow for anything other than 
> debugging) attempt here:
> https://github.com/claudeha/pure-data/tree/gui-tcl-robustness
> 
> It may reduce the impact of the error, or perhaps show further
> errors...
> > I don't have a small patch yet that triggers the problem, but will
> > try
> > to figure one out.
> 
> I reported something possibly-similar here:
> https://github.com/pure-data/pure-data/issues/488
> 
> toplevel patch contains a
> non-GOP abstraction which contains a
> GOP abstraction which
> sets iemgui properties on loadbang results in
> invalid command name tcl error
> > BTW.: this is with  0ee284ecfb5215
> > 
> 
> Claude

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Unnecessary scrollbars since 0.49

[Roman Haefeli]

(forgot to send to the list)

On Sun, 2018-09-23 at 03:12 +0200, Dan Wilcox wrote:
> Try this as a small test: add a new line with "return" after the
> "update idle tasks" on line 302 of tcl/pd_bindings.tcl.

I can't see a difference at first glance. Without having done an actual
measurement, it feels like in 50% of the cases of opening a subpatch
the unnecessary scrollbars are drawn and in the other 50% they are not.
This is with the 'return' addition and without.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Some patches broken in 0.49test3

[Roman Haefeli]

Hi

0.49test4 fixed the regression for me. I don't see any 'INVALID COMMAND
NAME' errors anymore. Claude told me in #dataflow, though, that he's
still able to trigger such errors.

Thanks,
Roman

On Sun, 2018-09-23 at 09:40 +0200, Roman Haefeli wrote:
> Hey Claude
> 
> It seems you already did the hard work. Sorry for not having checked
> more carefully. I'm glad attention is already paid to the issue.
> 
> Roman
> 
> On Sat, 2018-09-22 at 23:29 +0100, Claude Heiland-Allen wrote:
> > Hi Roman,
> > 
> > On 22/09/18 23:19, Roman Haefeli wrote:
> > > Hi
> > > 
> > > Sorry, need to report something probably more serious. Some of my
> > > patches trigger messages like the following:
> > > 
> > > 
> > > (Tcl) INVALID COMMAND NAME: invalid command name
> > > ".x558795b0c400.c"
> > >  while executing
> > > ".x558795b0c400.c itemconfigure 558795b682c0LABEL -font {{DejaVu
> > > Sans Mono} -11 bold}"
> > >  ("uplevel" body line 10)
> > >  invoked from within
> > > "uplevel #0 $docmds"
> > > 
> > > 
> > > Side effects are that sometimes the label of [cnv] is not
> > > updated.
> > > Or
> > > the canvas stays blank after dynamically creating stuff and
> > > objects
> > > are
> > > only shown after closing the window and opening it again.
> > 
> > You might try my (unfortunately too slow for anything other than 
> > debugging) attempt here:
> > https://github.com/claudeha/pure-data/tree/gui-tcl-robustness
> > 
> > It may reduce the impact of the error, or perhaps show further
> > errors...
> > > I don't have a small patch yet that triggers the problem, but
> > > will
> > > try
> > > to figure one out.
> > 
> > I reported something possibly-similar here:
> > https://github.com/pure-data/pure-data/issues/488
> > 
> > toplevel patch contains a
> > non-GOP abstraction which contains a
> > GOP abstraction which
> > sets iemgui properties on loadbang results in
> > invalid command name tcl error
> > > BTW.: this is with  0ee284ecfb5215
> > > 
> > 
> > Claude

signature.asc
Description: This is a digitally signed message part
___
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-0 released

[Roman Haefeli]

On Mon, 2018-09-24 at 20:56 -0700, Miller Puckette wrote:
> At long last...
> 
> Pd version 0.49-0 is available on http://msp.ucsd.edu/software.htm
> or (source only) via github: https://github.com/pure-data/pure-data

Cool. A  big 'thank you!' to everyone involved. All the work that went
into this release is very much appreciated.

Roman



signature.asc
Description: This is a digitally signed message part
___
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-0 released

[Roman Haefeli]

On Wed, 2018-09-26 at 13:34 +0200, Roman Haefeli wrote:
> On Mon, 2018-09-24 at 20:56 -0700, Miller Puckette wrote:
> > At long last...
> > 
> > Pd version 0.49-0 is available on http://msp.ucsd.edu/software.htm
> > or (source only) via github: https://github.com/pure-data/pure-data

One minor thing about the Windows archives: They contain a bunch of *.o
files in src/. Am I right in thinking that those are superfluous and
remnants of the compiling process?

signature.asc
Description: This is a digitally signed message part
___
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-0 released

[Roman Haefeli]

On Wed, 2018-09-26 at 08:06 -0700, Miller Puckette wrote:
> I think that's only true in the 32-bit version

Ah, you're right.

> which uses the old compilation scheme in which it's possible to edit
> the
> source code and recompile in place.  The ".o" files are there so that
> only
> the code you changed gets recompiled.

I see. Thanks.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] metro 1000 is 3 times faster than a second

[Roman Haefeli]

Hey

On Sun, 2018-09-30 at 20:55 +0200, Csaba Láng wrote:
> how is it possible that measuring a metro 1000 with realtime object i
> get 333.3 as a result?

I get same when running pd with -r 14700 while my soundcard is
configured to run at 44100Hz. Interestingly, this mismatch only has an
effect while DSP is on. When turning DSP off, [realtime] measures
1000ms.

> I am testing it on an Ubuntu 18.04 and time just goes 3 times faster
> than it should.

It's most likely not related to the OS. What soundcard are you using?

> On a Mac OS the result for the same test is expectedly 1000ms.
> Please advice!

On your Mac, there is apparently no mismatch between what SR Pd thinks
it gets from the soundcard and the actual soundcard setting.

Roman 

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] metro 1000 is 3 times faster than a second

[Roman Haefeli]

On Mon, 2018-10-01 at 12:15 +0200, Csaba Láng wrote:
> Thanks for the hints, probably the best idea is to turn off dsp every
> time it is not needed. However playing a video and audio with metro
> control (sending the bangs according to the frame rate) and using
> cameras in the same time makes pd totally loose sense of time. Very
> disappointing, as I trusted more in metro than in God.
> Popesz


Pd is designed to be deterministic. There is no notion of skipping some
task in order to keep synchronicity with real time, unlike many media
players that are able to skip frames in order to playback a movie file
with no interruption.

It has been discussed many times on this list about how to deal with
audio and video in Pd. Probably the best way is to run the audio and
video part in two separate instances of Pd, whereas the audio instance
does all the time-critical stuff and the video part is controlled by
the audio part through some communication channel (network socket, unix
socket, [pd~], etc.).

Roman


> On Sun, Sep 30, 2018 at 9:23 PM Jean-Marie Adrien <
> jm.adrien@gmail.com> wrote:
> > mabye you could set dsp on (and off again if needed) this will
> > synchronize pd in a more reasonable way
> > … and keep an eye permanently on this aspect if time measurement is
> > critical for ur patch
> > (high load might blow pd out, means 1 second is lasting three
> > seconds or so, in this latter case there is little to do besides
> > optimizing the patch)
> > JM
> > 
> > > Le 30 sept. 2018 à 20:55, Csaba Láng  a
> > écrit :
> > > 
> > > Dear list,
> > > 
> > > how is it possible that measuring a metro 1000 with realtime
> > object i get 333.3 as a result?
> > > I am testing it on an Ubuntu 18.04 and time just goes 3 times
> > faster than it should.
> > > On a Mac OS the result for the same test is expectedly 1000ms.
> > > Please advice!
> > > 
> > > 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


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] talk to php-website with netsend

[Roman Haefeli]

On Tue, 2018-10-02 at 10:29 +0200, Christof Ressi wrote:
> or you could just use [mrpeach/httpreq] :-)

Or [purest_json/rest]

Roman


> > Gesendet: Dienstag, 02. Oktober 2018 um 10:02 Uhr
> > Von: "IOhannes m zmoelnig" 
> > An: pd-list@lists.iem.at
> > Betreff: Re: [PD] talk to php-website with netsend
> > 
> > On 10/2/18 2:26 AM, Marco Hugo Schretter wrote:
> > > hi all,
> > > 
> > > is there a way to use netsend to talk to a php based website.
> > > 
> > > i'd like to send something corresponding to
> > > 
> > > :this works:
> > > [curl -s http://192.168.1.2/skript.php/?action=play(
> > > > 
> > > 
> > > [shell]
> > > 
> > > i'd like to get rid of [shell] (for windows etc) and do e.g.
> > > 
> > > :this does not work:
> > > [connect 192.168.1.2 80(
> > > > 
> > > > [send skript.php/?action=play(
> > > > /
> > > 
> > > [netsend]
> > 
> > netsend uses FUDI as the default protocol, which means that the
> > text you
> > are sending gets a terminating semicolon.
> > the receiver really sees "skript.php/?action=play;"
> > 
> > however, when you instruct curl to talk to a web-server, you are
> > using
> > the HTTP protocol, which is much more complex.
> > it really sends something like:
> > 
> > ~~~
> > GET /skript.php/?action=play HTTP/1.1
> > Host: 192.168.1.2
> > User-Agent: curl/7.61.0
> > Accept: */*
> > ~~~
> > 
> > with all the lines terminated with CRLF.
> > 
> > depending on your setup (e.g. now virtual-hosts involved), you
> > might get
> > away with a single CRLF-terminated line:
> > 
> > ~~~
> > GET /skript.php/?action=play HTTP/1.1
> > ~~~
> > 
> > now netsend has a binary-mode, which allows you to specify the raw
> > bytes
> > you want to transmit (no more FUDI): [netsend -b]
> > 
> > the only remaining hurdle is to create that list of bytes.
> > you could use [list fromsymbol] for this, but it only works on
> > symbols
> > (and not on lists of symbols).
> > so one way would be to serialize your message "GET /skript.php
> > HTTP/1.1"
> > into 3 1-symbol messages, convert those to lists of bytes with
> > [list
> > fromsymbol] and merge those lists into a single one, manually
> > adding the
> > connecting space (32) and the terminating CRLF (13 10).
> > 
> > an alternative is to use [fudiformat], which converts entire
> > messages
> > into FUDI bytelists (very similar to [list fromsymbol] for lists;
> > but
> > appends a terminating ";\n"), then split away the trailing two
> > bytes
> > (";\n" aka: 59 10) and append CRLF (13 10).
> > 
> > most likely, your server will require an explicit "Host" line, so
> > repeat
> > the above to get it.
> > 
> > if you are only ever sending the same string to the server, you
> > could of
> > course just translate the HTTP-requests into bytes once, and store
> > the
> > bytelist in your patch (which makes it a little harder to debug,
> > unless
> > you are good at translating decimal values to ascii)
> > 
> > 
> > vhscmtg
> > 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


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] trouble enabling Jack on Ubuntu compile

[Roman Haefeli]

On Fri, 2018-10-05 at 08:58 +0200, Max wrote:
> On 04.10.2018 23:58, Antoine Rousseau wrote:
> > maybe there is a way that the configure gives a better hint at
> > what's missing?
> > 
> > 
> > there is (at least) one: 
> > https://github.com/pure-data/pure-data/pull/507
> > ;-)
> 
> Awesome! Jokes aside, the installation has become a lot easier and 
> streamlined in the last couple of years and I would like to express
> my 
> gratitude to Dan, IOhannes, Miller and everyone involved in that.

+1

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] send~ and receive~ with blocksize different than Pd's?

[Roman Haefeli]

On Thu, 2018-11-01 at 14:46 +0100, Peter P. wrote:
> Hi,
> 
> I am trying to use a [block~ 1024 1 16] object in a subpatch to
> oversample 16 times. If this subpatch uses send~ and receive~
> objects,
> or throw~ and catch~ Pd reports the error that:
>   receive~ foo: vector size mismatch
>   sigsend foo: unexpected vector size
> If I set the blocksize of the subpatch to Pd's blocksize with
> [block~ 64 1 16] things work.
> 
> I assume that send~ and receive~ and friends can run at Pd's
> blocksize only?

Yes, and the help of [send~ ] clearly states so. And it also provides
the solution: use [tabsend~ ], [table] and [tabreceive~]. Those work
for all block sizes, but obviously only if [table] >= block size. 

I don't know if there is a block size agnostic substitution for
[throw~] and [catch~] (many senders, one receiver). I can't think of
one.

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] monitoring function REC-Play for looper

[Roman Haefeli]

On Thu, 2018-11-08 at 13:23 +0100, Clemens wrote:
> But what do you mean with "fan-outs"?

A fan-out in Pd usually means that a single outlet is connected to two
or more inlets. IOhannes strongly advises you to get rid of them,
because the order the many inlets receive the message from the outlet
is not defined. This is the single-most frequent source of bugs in Pd
patches. 


> and how can I get rid of them?

Replace any occurrence of a fan-out by an appropriate [trigger] object.

Example:

[bla]
|\
| \
|  \
[y] [x]

should be replaced by:

[bla] 
|
[trigger anything anything]
| |
[y]   [x]

(use mono space font for this ASCII-art to make sense)

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] German translation of Pd

[Roman Haefeli]

On Fri, 2018-11-09 at 12:09 +0100, Max wrote:
> On 09.11.18 01:16, Simon Iten wrote:
> > 
> > > On 8 Nov 2018, at 15:58, IOhannes m zmoelnig  > > > wrote:
> > > 
> > > none of them ring with me.
> > > both "knopf" and "schalter" evoke quite specific images in my
> > > head, none
> > > of which match with what you actually get (and “radiobutton" does
> > > neither)
> > 
> > Selektor?
> > 
> 
> I like

-1

It collides with the English 'selector' which has a particular meaning
in Pd.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] No current Gem for OS X?

[Roman Haefeli]

On Tue, 2018-11-13 at 12:10 +0100, Jean-Marie Adrien wrote:

> does it mean that GEM will not work on mac OsX mojave ??
> gasp ! 
> :(

If that is the first time you gasp while using a Mac, then call
yourself lucky!

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] time/date objects in zexy

[Roman Haefeli]

On Sun, 2018-11-18 at 11:08 -0600, Rick Snow wrote:
> The time and date objects in the current zexy are not loading on
> macOS High Sierra.  When I pull the .pd_darwin files from an old pd-
> extended resources/extra/zexy folder they do load.

Make sure to load the library. Only adding the path is not sufficient
for multi-object libraries like zexy. Since pd-extended compiled all
objects into their own file, everything loads by only specifying the
path. (The pd-extended way had its own quirks with certain objects with
special characters in their name). 

BTW: Some objects of the new zexy still do load, because some of the
objects are provided as both, compiled external and abstraction. 

Roman


 



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] time/date objects in zexy

[Roman Haefeli]

On Mon, 2018-11-19 at 13:30 -0200, Alexandre Torres Porres wrote:
> 
> 
> Em seg, 19 de nov de 2018 às 12:43, IOhannes m zmoelnig <
> zmoel...@iem.at> escreveu:

> > better yet: use [declare -path zexy -lib zexy]
> 
> doesn't just [declare -lib zexy] work?

No, some objects like [rad2deg] are provided only as abstractions.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] case-sensitivity for filenames of abstractions on different OSes?

[Roman Haefeli]

On Tue, 2018-11-20 at 15:26 +0100, Peter P. wrote:
> Hi,
> 
> is it possible that an abstraction loads as  [myabs] when only a
> myAbs.pd file is present under OS X? 

Yes, I believe so.

> I thought that filenames on Unix Systems are case sensitive and that
> they are not so on Windows.

Depends on how the HFS+ filesystem was created. Both, case sensitive
and case insensitive are possible. I think some filesystems typically
used on Linux may have a feature to do case insensitive look-ups, but
the common case is case sensitive. 

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla OSC message format

[Roman Haefeli]

On Fri, 2018-11-23 at 22:37 +0100, Max wrote:
> 
> [symbol vector(
> |
> [oscformat -f s subscribe @ blender Root]

Try this:

[bang(
|
[oscformat subscribe @ blender Root vector]

It should give you the byte-identical result as [packOSC] output.

> [netreceive {port} 1]

That's ok if you expect FUDI messages from UDP. But you want binary
output as lists of floats. Use:

[netreceive -u -b {port} ]

If that still doesn't work, then you might post the raw output from
[netreive] of an incoming OSC packet here. This will help analyze
what's going on.

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Network crashes pd

[Roman Haefeli]

On Wed, 2018-12-05 at 15:00 +0100, Orm Finnendahl wrote:
> 
>  I experience sudden pd crashes 

How does Pd crash? Is it segfaulting? Does it freeze and you have to
restart?

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Deken - question / feature request

[Roman Haefeli]

Hi

On Sun, 2018-12-09 at 14:17 +0100, João Pais wrote:
> I need to distribute a patch, which has to be programmed in Pd
> Vanilla but  
> with some external libraries. Since the patch will be downloaded by  
> unexperienced persons, 
> it would be good that the externals would be  
> automatically installed by deken. 

You could also create an all-in-one bundle, containing your patch and
abstractions, the externals and a copy of Pd. By modifying tcl/pd-
gui.tcl you can make Pd automatically load your patch.

There might be many reasons not to do it this way, but it is certainly
very easy for little-experienced end-users. 

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] name of latency measurement algorithm

[Roman Haefeli]

Hey all

I once read about a simple and robust way to perform latency
measurements with an audio signal. 

Explained in a few words, the test signal consists of a sweeping sine
tone. The return signal ring-modulates the source signal and the
resulting signal consists of two frequencies, the sum ( f_src+f_ret ) 
and difference ( f_src - f_ret), while the lower frequency is
proportional to the latency and can be detected quite easily with  with
e.g. [sigmund~].

I have troubles finding the name of this algorithm and don't remember
the original source. I would like to read more about it and correctly
attribute the original author / inventor.

Thanks,
Roman  


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] name of latency measurement algorithm

[Roman Haefeli]

On Thu, 2018-12-13 at 13:21 +0100, Peter P. wrote:
> * Roman Haefeli  [2018-12-13 11:58]:
> > Hey all
> > 
> > I once read about a simple and robust way to perform latency
> > measurements with an audio signal. 
> > 
> > Explained in a few words, the test signal consists of a sweeping
> > sine
> > tone. The return signal ring-modulates the source signal and the
> > resulting signal consists of two frequencies, the sum ( f_src+f_ret
> > ) 
> > and difference ( f_src - f_ret), while the lower frequency is
> > proportional to the latency and can be detected quite easily
> > with  with
> > e.g. [sigmund~].
> > 
> > I have troubles finding the name of this algorithm and don't
> > remember
> > the original source. I would like to read more about it and
> > correctly
> > attribute the original author / inventor.
> 
> See jack_delay on https://kokkinizita.linuxaudio.org/linuxaudio/

That's a different algorithm and probably much more precise. The one
I'm looking for is simpler (and I'd probably know how to implement it
in Pd).

Anyway, thanks for the input. It's certainly an interesting approach,
too.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] name of latency measurement algorithm

[Roman Haefeli]

On Thu, 2018-12-13 at 15:09 +0100, Peter P. wrote:
> * Roman Haefeli  [2018-12-13 13:52]:
> > On Thu, 2018-12-13 at 13:21 +0100, Peter P. wrote:
> > > * Roman Haefeli  [2018-12-13 11:58]:
> > > > Hey all
> > > > 
> > > > I once read about a simple and robust way to perform latency
> > > > measurements with an audio signal. 
> > > > 
> > > > Explained in a few words, the test signal consists of a
> > > > sweeping
> > > > sine
> > > > tone. The return signal ring-modulates the source signal and
> > > > the
> > > > resulting signal consists of two frequencies, the sum (
> > > > f_src+f_ret
> > > > ) 
> > > > and difference ( f_src - f_ret), while the lower frequency is
> > > > proportional to the latency and can be detected quite easily
> > > > with  with
> > > > e.g. [sigmund~].
> > > > 
> > > > I have troubles finding the name of this algorithm and don't
> > > > remember
> > > > the original source. I would like to read more about it and
> > > > correctly
> > > > attribute the original author / inventor.
> > > 
> > > See jack_delay on https://kokkinizita.linuxaudio.org/linuxaudio/
> > 
> > That's a different algorithm and probably much more precise. The
> > one
> > I'm looking for is simpler (and I'd probably know how to implement
> > it
> > in Pd).
> 
> What about 7.stuff/tools/latency.pd?

Cool, the collection of algorithms is growing :-)

This is again a different approach. The test signal is a pulse and the
patch measures time between sending and receiving the click. The cool
thing is it's done in a way that doesn't need any "magic" objects like
[sigmund].

However, it's still not the one I was describing earlier.

Roman 



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] ugly font edges on non-black background

[Roman Haefeli]

I can't reproduce with the help of [text3d].

Have you tried using  a TrueType font?

Gruss
Roman

On Tue, 2019-01-08 at 16:32 +0100, Csaba Láng wrote:
> Dear list,
> 
> I would like to use [text3d] texts on yellow background but the edge
> of the texts are so ugly that I am concerning to use prerendered
> images on alpha channel.
> Not even mentioning the inside part of the letters/numbers which are
> black anyway.
> Is there a way to achieve beautiful texts which are on transparent
> background?
> 
> Tried with alpha with all the numeric possibilities alpha offers (on
> 16 pd crashes) but without any success.
> 
> Please advice!
> 
> Best,
> 
> Popesz
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

Hi

It performs even better than William Brent's [convolve~] external, even
with small delays. When both set to 256, I get 9% load vs. 26%.

However, I get artefacts with a setting of 64 samples. When loading the
various IRs, the result sometimes sounds glitchy. Setting of 128 or
higher are always fine, regardless of IR.

Also with the church.wav and a setting of 64 you can hear the glitches
by feeding it a [phasor~ 5].

BTW: I can load many instances just fine (Pd 0.49 on Linux amd64)

Thanks for sharing!

Roman

On Tue, 2019-01-08 at 22:54 +0100, Philipp Schmalfuß wrote:
> Hi Alexandre,
> 
> i made a pd-vanilla abstraction for real time convolution a while
> ago.  
> it is part of a collection of pd abstractions that i am planning to  
> share with the community, soon...
> it loosely follows gardner's approach  
> http://www.cs.ust.hk/mjg_lib/bibs/DPSu/DPSu.Files/Ga95.PDF
> 
> with this, i get about 8-10% cpu-load with the church-IR and 64  
> samples min. fft-blocksize on an old lenovo t430 running linux.  
> however, i get the ugly clicks when i have more than one instance
> of  
> the abstraction running and on windows it causes pd-crashes, so i'm  
> not perfectly happy.
> i think it could be improved a lot by precomputing the IR like in
> your patch.
> 
> https://we.tl/t-HYsWQww10V
> 
> cheers!
> 
> Quoting Alexandre Torres Porres :
> 
> > Bug, for some reason, you may need to recreate the object so the
> > sound
> > comes out. I have no idea yet why...
> > 
> > Em ter, 8 de jan de 2019 às 14:52, Alexandre Torres Porres <
> > por...@gmail.com>
> > escreveu:
> > 
> > > oops, I hads uploaded the wrong file, here's the hopefully
> > > correct and
> > > last word on it
> > > 
> > > https://www.dropbox.com/s/05xl7ml171noyjq/convolution~.zip?dl=0
> > > 
> > > and my CPU load is actually at about 57%, not 50%
> > > 
> > > The last file I uploaded was using a compiled object to perform
> > > the
> > > complex multiplication and that helped a little with the
> > > efficiency. I'm
> > > gonna use it for my non vanilla abstraction that I'm bringing
> > > into my ELSE
> > > library.
> > > 
> > > cheers
> > > 
> > > 
> > > 
> > > Em ter, 8 de jan de 2019 às 14:13, Alexandre Torres Porres <
> > > por...@gmail.com> escreveu:
> > > 
> > > > Ok, here's the new deal...
> > > > 
> > > > https://www.dropbox.com/s/l69gzv98g3th5d1/conv.rev~.zip?dl=0
> > > > 
> > > > there are two subpatches for testing, one is light with a
> > > > relative big
> > > > window partition (1024) and a short Impulse Response (2 secs).
> > > > 
> > > > The other is quite heavy, it's an 8 sec long IR with a window
> > > > size of
> > > > 512! This one takes just a bit over 50% of my CPU power, and
> > > > I'm on a last
> > > > generation macbook pro (2.6Ghz processor)... but I need to
> > > > increase the
> > > > Delay (msec) from 5 to 10 in the audio settings, otherwise I
> > > > get terrible
> > > > clicks!
> > > > 
> > > > William Brent's convolve is ridiculously much more efficient,
> > > > the same
> > > > parameters take about 14% of my CPU power and I can use a delay
> > > > of 5 ms in
> > > > the audio settings.
> > > > 
> > > > But anyway, this is useful for teaching and apps that implement
> > > > a light
> > > > convolution reverb (short IR/not too short window) need pure
> > > > vanilla
> > > > (libpd/camomille and stuff)
> > > > 
> > > > Cheers!
> > > > 
> > > > Em dom, 6 de jan de 2019 às 14:25, Alexandre Torres Porres <
> > > > por...@gmail.com> escreveu:
> > > > 
> > > > > Meanwhile, I deleted the original file so people can't get it
> > > > > anymore :)
> > > > > 
> > > > > Em dom, 6 de jan de 2019 às 14:16, Alexandre Torres Porres <
> > > > > por...@gmail.com> escreveu:
> > > > > 
> > > > > > Hi, quick updates and developments over my weekend
> > > > > > 
> > > > > > 
> > > > > > > On Thursday, 3 January 2019, 04:19:50 GMT, Alexandre
> > > > > > > Torres Porres <
> > > > > > > por...@gmail.com> wrote:
> > > > > > > 
> > > > > > > what you think, is it working?
> > > > > > 
> > > > > > 
> > > > > > So, the patch/algorithm was wrong and I've fixed
> > > > > > 
> > > > > > 
> > > > > > > Both objects on the help file take about 40% of my CPU
> > > > > > > power, but I'm
> > > > > > > on a wild machine
> > > > > > > 
> > > > > > 
> > > > > > I was able to do a few more things and make it much more
> > > > > > efficient
> > > > > > 
> > > > > > 
> > > > > > > I tried the idea of having each partition work with FFT
> > > > > > > saved on
> > > > > > > tables, so we wouldn't need to perform FFTs in different
> > > > > > > instances of
> > > > > > > clone, but that doesn't seem to be possible.
> > > > > > 
> > > > > > 
> > > > > > This is because things were wrong, like I said, now that
> > > > > > I've fixed it,
> > > > > > that was possible.
> > > > > > 
> > > > > > But my current version is not vanilla anymore, as I'm
> > > > > > developing this
> > > > > > object to include it in my "ELSE" library. Once I'm done
> > > > > > I'll t

Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

On Wed, 2019-01-09 at 11:27 -0200, Alexandre Torres Porres wrote:
> yeah, I also get lots of glitches and artifacts with a 64 minimum
> window. I have to increase the delay up to 50ms so I get rid of them,
> which is kinda bad, even though it seems incredibly efficient. 

Just to clear: I'm not experiencing Pd glitches at any configured audio
setting whatsoever. What I mean is the abstractions produces 'wrong'
results when configured to 64. I don't understand enough to give any
hint why 128 is still fine and 64 sounds off.

> Brent is not using gardner's approach I assume. And what this does is
> that it increases the window over and over in the following
> partitions, this is why it gets so much lighter on the CPU

Yeah. From what I gather without reading William Brent's [convolve~]'s
source code, is that it uses n partitions with same size. At least the
printed number seems to suggest that. Thus, using a smaller delay leads
to a significantly increased CPU load. With Gardener's approach, the
penalty of a short delay is almost not noticeable.

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

On Wed, 2019-01-09 at 13:44 -0200, Alexandre Torres Porres wrote:
> hmm, weird, I don't seem to find problems...

Aha? Even with attached test3.pd patch saved along the original test.pd
patch? You can compare 64 to 128 and I get a glitchy tone with a
frequency of 690 Hz (which seems to come from 44100/64).

Have you tried other IRs than the church.wav and IR.wav?

Roman


#N canvas 585 289 400 393 10;
#X msg 191 294 \$1 10;
#X obj 192 314 line~;
#X obj 193 250 hsl 128 15 0 1 0 0 empty empty empty -2 -8 0 10 -228856
-1 -1 10600 1;
#X obj 53 318 dac~;
#X msg 146 117 loadIR ./church.wav;
#X obj 65 161 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X obj 14 272 *~;
#X obj 15 22 phasor~ 5;
#X obj 190 270 pow 4;
#X text 82 161 switch~;
#N canvas 193 363 450 300 conv64 0;
#X obj 43 71 inlet~;
#X obj 60 265 outlet~;
#X obj 237 71 inlet;
#X obj 316 84 inlet;
#X obj 316 155 switch~;
#X obj 63 148 pp.fft-partconv~ 64;
#X connect 0 0 5 0;
#X connect 2 0 5 2;
#X connect 3 0 4 0;
#X connect 5 0 1 0;
#X restore 14 234 pd conv64;
#X obj 171 166 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1
1;
#X text 188 166 switch~;
#N canvas 193 363 450 300 conv128 0;
#X obj 43 71 inlet~;
#X obj 60 265 outlet~;
#X obj 237 71 inlet;
#X obj 316 84 inlet;
#X obj 316 155 switch~;
#X obj 63 148 pp.fft-partconv~ 128;
#X connect 0 0 5 0;
#X connect 2 0 5 2;
#X connect 3 0 4 0;
#X connect 5 0 1 0;
#X restore 114 234 pd conv128;
#X obj 114 269 *~;
#X obj 146 22 loadbang;
#X obj 146 45 t b b;
#X msg 173 70 dsp 1;
#X obj 173 93 s pd;
#X connect 0 0 1 0;
#X connect 1 0 6 1;
#X connect 1 0 14 1;
#X connect 2 0 8 0;
#X connect 4 0 10 1;
#X connect 4 0 13 1;
#X connect 5 0 10 2;
#X connect 6 0 3 0;
#X connect 7 0 10 0;
#X connect 7 0 13 0;
#X connect 8 0 0 0;
#X connect 10 0 6 0;
#X connect 11 0 13 2;
#X connect 13 0 14 0;
#X connect 14 0 3 1;
#X connect 15 0 16 0;
#X connect 16 0 4 0;
#X connect 16 1 17 0;
#X connect 17 0 18 0;


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] speed

[Roman Haefeli]

On Fri, 2019-01-11 at 13:20 +0100, michael strohmann wrote:
> ok, then there might be the problem.
> i was thinking that [line] runs thru ALL the numbers in different
> speeds.

No.

> which, come to think of it, might be a problem if i ask it to run
> from 0 to 10 in 10 ms.

That's not the problem. You can create something in Pd that counts to
100'000 in zero logical time. Your initial question suggests that you
lack an understanding of some fundamental design aspects of Pd. One
important thing to know is that Pd does everything in a deterministic
manner. Regardless of whether it runs on a very slow or very fast
computer, the generated results are always the same. The only
difference is that it might be able to do it in real time on one
computer while it suffers drop-outs and glitches on another. When you
know that, you know that the rate at which [line] is emitting numbers
is not related to the speed of the CPU.

Forgive me if I sound patronizing, but let me say it anyway: Pd is much
more fun when you understand how it works. Read at least the manual
that is shipped along with the software.

> so, what is the actually algotithm the [line] object is using?

Check the help of line. I cannot explain it better than that. Key words
are 'time grain' and 'grain rate'.

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] speed

[Roman Haefeli]

On Sat, 2019-01-12 at 20:44 +, Jonathan Wilkes wrote:
> >On Friday, January 11, 2019, 8:12:46 AM EST, Roman Haefeli <
> reduz...@gmail.com> wrote:
> 
> >> so, what is the actually algotithm the [line] object is using?
> 
> > Check the help of line. I cannot explain it better than that. Key
> words
> are 'time grain' and 'grain rate'.
> 
> Hi Roman,
> 
> What does "grain rate" mean?

The rate at which [line] outputs an update of the current value. I'd
probably call the second argument "grain period" as "grain rate"
implies a frequency.

> Specifically-- if the default grain rate is 20ms, what does that mean
> for 
> the schedule upon which [line] will output messages over the course
> of 
> a given ramp's duration?

I'm not sure I fully understand what your asking. Upon receiving a two-
float list, [line] starts sending out messages at the given rate. The
time period between the message reflects the second argument, except
for the time period between the second to last and last message where
the period might be shorter so that the sum of all grains equals the
ramp time given.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] vanilla partitioned convolution abstraction

[Roman Haefeli]

On Sat, 2019-01-12 at 22:56 -0200, Alexandre Torres Porres wrote:
> Em sex, 11 de jan de 2019 às 19:25, Alexandre Torres Porres <
> por...@gmail.com> escreveu:
> > So it seems this delay scheme needs to be revised, and maybe that's
> > why the minimum window size of 64 gives us some weird artifacts!
> > 
> 
> Actually, based on another thread I opened here on the list, it seems
> the minimum hop size for an overlap needs to be 64, so [block~ 64 2]
> wouldn't really work... this means that starting with a window of 64
> samples could raise issues, hence it might be the actual culprit! 

I haven't fully grasped your patch illustrating the issue yet, but you
seem to have identified the problem. Well done! I'm already totally
happy with the partitioned convolutions presented here and with the
current minimum delay of 128 samples. I'm curious, though, whether it's
possible to maintain correct results with smaller delays by treating
smaller block sizes differently.

Roman 


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] open [openpanel] window in the patch folder

[Roman Haefeli]

On Tue, 2019-01-15 at 13:35 +, Mario Buoninfante wrote:

> Would it be possible to use something like the following
> 
> [symbol ./(
> |
> |
> [openfolder]
> 
> to open the dialog window in the current patch folder?
> 
> This syntax works when you save or load files (ie with [textfile]),
> but doesn't seem to work with [openpanel] and [savepanel].

The help file says that you can use [symbol ( to open a
specific directory. However, when you give a relative path, it is
relative to Pd's start location, which is pretty useless. 

I am in favor of your suggestions. For this to work, pathes should be
relative to the patch, which would make much more sense, imho.

Roman




signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] open [openpanel] window in the patch folder

[Roman Haefeli]

On Tue, 2019-01-15 at 13:28 -0200, Alexandre Torres Porres wrote:
> 
> 
> Em ter, 15 de jan de 2019 às 12:30, Roman Haefeli  > escreveu:
> > On Tue, 2019-01-15 at 13:35 +, Mario Buoninfante wrote:
> > 
> > > Would it be possible to use something like the following
> > > 
> > > [symbol ./(
> > > |
> > > |
> > > [openfolder]
> > > 
> > > to open the dialog window in the current patch folder?
> > > 
> > > This syntax works when you save or load files (ie with
> > [textfile]),
> > > but doesn't seem to work with [openpanel] and [savepanel].
> > 
> > The help file says that you can use [symbol ( to open a
> > specific directory. However, when you give a relative path, it is
> > relative to Pd's start location, which is pretty useless. 
> 
> is it? cause it seems to me it's just not working at all!

I can currently only test on Linux, but yes it works. However, when
banging [openpanel] initially, it doesn't open in Pd's start location,
but in its "Home" which happens to be ~/Documents/Pd in my version of
Pd (0.49.1). When sending [symbol .(, it opens the directory I started
Pd from. I can open any directory when specifying it relative to the
one shown by [symbol .( . If the given relative path cannot be
resolved, it opens . (the start location) instead.

I don't know what the start location is on platforms where you double-
click an icon to launch the application. But you can easily figure that
out by sending [symbol .( to [openpanel]. From there, relative paths
should work. I guess, they do so also on macOS and on Windows once you
know where your starting point is. 

What I was trying to say  in my previous post is that relative paths
are pretty useless when they must be relative to this arbitrary
starting point, since the patch has no notion of that path. Most often
you want [openpanel] to show some directory relative to the main patch
of your project. For me, relative to patch would make much more sense.
I don't see any meaningful use case with the current implementation of
'relative to Pd's start location'. 

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] open [openpanel] window in the patch folder

[Roman Haefeli]

On Tue, 2019-01-15 at 14:08 -0200, Alexandre Torres Porres wrote:
> 
> 
> Em ter, 15 de jan de 2019 às 13:56, Roman Haefeli  > escreveu:
> > 
> > I can currently only test on Linux, but yes it works. However, when
> > banging [openpanel] initially, it doesn't open in Pd's start
> > location,
> > but in its "Home" which happens to be ~/Documents/Pd in my version
> > of
> > Pd (0.49.1).
> 
> that's actually 0.49-0, right? 49.1 is only for mac

0.49.1 is what Pd shows. I compiled it myself, so maybe I'm using a
version where the most recent changes affect only macOS.

> > I don't know what the start location is on platforms where you
> > double-
> > click an icon to launch the application. But you can easily figure
> > that
> > out by sending [symbol .( to [openpanel]. 
> 
> Sending a "symbol ." here in the latest macOS and Pd opens the root
> of HD 
>  
> > From there, relative paths should work. I guess, they do so also on
> > macOS and on Windows once you
> > know where your starting point is. 
> 
> So, a bang opens ~/Documents/Pd, but no relative paths work from
> there!

I try to make myself more clear: [bang ( opens  what I called `Pd's
Home`. In order to use relative paths you send it [symbol .( and this
path is what I called Pd's start location. Relative paths work only
relative to what [symbol .( shows, NOT to what [bang( shows.


> So it seems like a bug for mac, and also, we want the behaviour to be
> relative to the patch's path, right? At least when sending it "symbol
> ./"

It's not a bug, unless you say, that paths are not even working
relative to  what [symbol .( shows. You haven't said that yet. You only
said, that it is not working relative to what [bang ( shows.

Roman



signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] issue reading SysEx files

[Roman Haefeli]

On Mon, 2019-01-21 at 10:03 +0100, Antoine Rousseau wrote:
> > make an addition to soundfiler to read binary characters into an
> > array.
> 
>  wouldn't "read -raw 0 1 1 n" work?

It would be cool if -raw would allow 1 byte per sample. But even if it
worked this way, the result would be scaled to the range of -1 to 1,
which is not so handy. A way to read bytes represented in the array as
numbers in the range of 0 to 255 would make [soundfiler] really useful
for dealing with binary files.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [text] issue reading SysEx files

[Roman Haefeli]

On Mon, 2019-01-21 at 13:34 +0100, IOhannes m zmoelnig wrote:
> On 21.01.19 12:48, Roman Haefeli wrote:
> > On Mon, 2019-01-21 at 10:03 +0100, Antoine Rousseau wrote:
> > > > make an addition to soundfiler to read binary characters into
> > > > an
> > > > array.
> > > 
> > >  wouldn't "read -raw 0 1 1 n" work?
> > 
> > It would be cool if -raw would allow 1 byte per sample. But even if
> > it
> > worked this way, the result would be scaled to the range of -1 to
> > 1,
> > which is not so handy. A way to read bytes represented in the array
> > as
> > numbers in the range of 0 to 255 would make [soundfiler] really
> > useful
> > for dealing with binary files.
> 
> 
> attached is a vanilla abstraction to read binary files like
> [mrpeach/binfile].

Sweet! Thanks for sharing.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] hid

[Roman Haefeli]

On Thu, 2019-01-24 at 11:00 +0100, IOhannes m zmoelnig wrote:
> On 24.01.19 10:46, Raphael Isdant wrote:
> > I didn't tried it yet, but you can find a compiled version
> 
> you could also just try to compile [hid] (and upload it to deken).
> i don't think it's super hard.


I tried with hid-0.7 from puredata.info and wasn't successful on macOS
Yosemite and Sierra.

It fails at:

HID Utilities Source/HID_Utilities_External.h:64:9: error: mac68k alignment 
pragma is not supported on this target
#pragma options align=mac68k

But also when I comment out that line, it fails with a different error.

It seems the included header files originating from Apple are pretty
outdated. 

Maybe I tell rubbish, but at least it seems [hid] needs some love from
someone with a bit deeper knowledge of things.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list