Re: [PD] recursive searching with [text search]

[Liam Goodacre]

I think that the second option of outputting multiple matches together would be 
the simplest and most useful. It should definitely be an optional feature 
though, otherwise it would again damage old patches which use [text search] and 
are expecting only one match. A simple -r flag would seem sufficient for this.

I would also suggest that the output should be a sequence of floats, rather 
than a list. This seems more consistent with other PD objects, and more useful, 
since you probably want to [get] the matches immediately anyway. But this is a 
minor detail.

I can see that the first option of introducing ranges is more powerful and 
opens up more possibilities. However, I'm guessing it would require a new inlet 
on the object, and the second inlet on [text search] is already taken for 
setting the pointer. So you'd either need to break backwards compatibility for 
[text search], or break the convention of the pointer being the farthest right 
inlet.

However, I have another idea for fixing ranges in [text search]. You can 
currently search in specific fields using arguments (so [text search mytext 0 
1] allows you to search in the 1st and 2nd fields of the text only). I suggest 
a special field--say "-1" or "range"--that allows you to search against the 
line number. So for instance, searching "cat 5 10" into [text search mytext 0 < 
field > field] would search for a text entry after line number 5 but before 10 
with "cat" as its 1st term. This would allow you to access ranges without 
having to worry about new inlets.

I've suggested this before and I still think that it would be a great feature. 
However, I don't think that it would be the best solution for recursive 
searching, and I would love to see a new "-r" feature and a "range" feature 
implemented together. I say this because 1: using ranges to achieve multiple 
results is not trivial--not for new users anyway, and especially not compared 
to a simple "-r" flag. And 2: I'm guessing that it would be less efficient.


From: Miller Puckette 
Sent: 21 July 2018 13:28
To: Liam Goodacre
Cc: PD list
Subject: Re: [PD] recursive searching with [text search]

I keep thinking about that too.  One idea would be to specify a range of
lines to search in, so that one could use the results of the previous search
to start teh next one.

Another would be to output a list of ALL search-matches.

cheers
Miller

On Sat, Jul 21, 2018 at 09:10:57AM +, Liam Goodacre wrote:
> People often ask about how to get multiple matches with [text search] (see 
> here).
>  There are a few ways of doing it but none of them are very optimal, and it 
> seems like something that would be much easier and more efficient if it were 
> implemented with code.
>
> Would there be any traction for a new feature, say [text search -r], to allow 
> for recursive searching?

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

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

Re: [PD] [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

Re: [PD] recursive searching with [text search]

[José de Abreu]

Liam, there are many objects that change the number of inlets when is
instantiated differently... so, when you give the -r flag, the text search
could be, by default, give all the matches, but also create more inlets to
set the range, and if you set a -1 to (bigger than max number of lines)
range, it will give all the matches again.

Miller, what about this?

Em Qua, 25 de jul de 2018 04:43, Liam Goodacre 
escreveu:

> I think that the second option of outputting multiple matches together
> would be the simplest and most useful. It should definitely be an optional
> feature though, otherwise it would again damage old patches which use [text
> search] and are expecting only one match. A simple -r flag would seem
> sufficient for this.
>
> I would also suggest that the output should be a sequence of floats,
> rather than a list. This seems more consistent with other PD objects, and
> more useful, since you probably want to [get] the matches immediately
> anyway. But this is a minor detail.
>
> I can see that the first option of introducing ranges is more powerful and
> opens up more possibilities. However, I'm guessing it would require a new
> inlet on the object, and the second inlet on [text search] is already taken
> for setting the pointer. So you'd either need to break backwards
> compatibility for [text search], or break the convention of the pointer
> being the farthest right inlet.
>
> However, I have another idea for fixing ranges in [text search]. You can
> currently search in specific fields using arguments (so [text search mytext
> 0 1] allows you to search in the 1st and 2nd fields of the text only). I
> suggest a special field--say "-1" or "range"--that allows you to search
> against the line number. So for instance, searching "cat 5 10" into [text
> search mytext 0 < field > field] would search for a text entry after line
> number 5 but before 10 with "cat" as its 1st term. This would allow you to
> access ranges without having to worry about new inlets.
>
> I've suggested this before and I still think that it would be a great
> feature. However, I don't think that it would be the best solution for
> recursive searching, and I would love to see a new "-r" feature and a
> "range" feature implemented together. I say this because 1: using ranges to
> achieve multiple results is not trivial--not for new users anyway, and
> especially not compared to a simple "-r" flag. And 2: I'm guessing that it
> would be less efficient.
>
> --
> *From:* Miller Puckette 
> *Sent:* 21 July 2018 13:28
> *To:* Liam Goodacre
> *Cc:* PD list
> *Subject:* Re: [PD] recursive searching with [text search]
>
> I keep thinking about that too.  One idea would be to specify a range of
> lines to search in, so that one could use the results of the previous
> search
> to start teh next one.
>
> Another would be to output a list of ALL search-matches.
>
> cheers
> Miller
>
> On Sat, Jul 21, 2018 at 09:10:57AM +, Liam Goodacre wrote:
> > People often ask about how to get multiple matches with [text search]
> (see here<
> https://forum.pdpatchrepo.info/topic/11504/multiple-search-results-in-text>).
> There are a few ways of doing it but none of them are very optimal, and it
> seems like something that would be much easier and more efficient if it
> were implemented with code.
> >
> > Would there be any traction for a new feature, say [text search -r], to
> allow for recursive searching?
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] FANN external for neural nets

[William Brent]

Hi all,

I wanted to try out Davide Morelli's [ann_mlp] object, which uses the FANN
library for neural nets, and found that some of the FANN functions it uses
no longer work as of FANN 2.0. I decided to take it on and update things to
get basic functionality going, and then went further to add access to
additional/new FANN options and create an in-depth help file as well.

It's been useful to me in timbre classification problems, and if there
isn't already a current go-to neural net option for Pd that I just don't
know about, I feel like this would be a great tool to put out there again.
I'm happy to share this source code/help file, but I wanted to see if
[ann_mlp] is something Davide or anyone else still wants to maintain as
part of the [ann] library. I also see that Iohannes and Georg Holzmann put
in work on [ann], and I'm wondering about its status for the future. I
don't think I'll be taking on updating the other objects in [ann], so one
option would be for me to put my updated version of Davide's [ann_mlp] out
in the world on its own for now. I've been calling it [fann] in my own use
since it's a direct interface for FANN functions.

Any thoughts on this? Is there another neural net package for Pd that I'm
totally ignorant of? A more current version of [ann] using FANN 2.0 that I
just didn't come across in my searches?

William



-- 
William Brent
www.williambrent.com

“Great minds flock together”
Conflations: conversational idiom for the 21st century

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

Re: [PD] [PD-announce] Camomile v1.0.6 - LV2 support, PdStalFx, Audio Buses, etc.

[Pierre Guillot]

>
> You had a video tutorial on how to generate
> plugins before, I think this is also a nice feature to dedicate another
> video showing how easier it is now ;)


Here it is: https://vimeo.com/281661482.
I will do the linux version of the video soon!

Cheers,
Pierre

Le lun. 16 juil. 2018 à 11:00, Pierre Guillot  a
écrit :

>
>
>> I just realized this is also another feature I had requested that must
>> really facilitate things. You had a video tutorial on how to generate
>> plugins before, I think this is also a nice feature to dedicate another
>> video showing how easier it is now ;)
>
>
> Yes, this video should be easy to do.
>
>  Oh, and, by the way, I'm more than willing to support this project by
>> adding support to my externals - you wouldn't need to worry on maintaining
>> that.
>
>
>> But I needed to know what I had to do...
>
>
> Thanks, it's really appreciated! There is a thread on the pd forum where I
> speak about it (
> https://forum.pdpatchrepo.info/topic/11242/camomile-v1-0-1-an-audio-plugin-with-pure-data-embedded/13).
> One idea could be to create a parallel distribution, some kind of
> Camomile-extended, but I'm not sure that's the good approach (in fact, I'm
> pretty sure it's not). I would prefer to have the dynamic libraries
> alongside the patches and, if necessary, to let libraries devs to manage
> the multiinstance/multithread support (most of the time it's not hard to
> do) and offering a special version of their libraries. Anyway, for the
> first approach I can make an example with the freeverb external and let
> people do the same with their libraries if they want to have their own
> Camomile distribution. And if you want to have a first look, the first step
> would be to compile Camomile, it's pretty easy and straightforward (on Mac
> there is one solution that compile everything and on Linux one makefile),
> see the readme:
> https://github.com/pierreguillot/Camomile/blob/master/README.md#compilation
> .
>
> Cheers
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] FANN external for neural nets

[Dan Wilcox]

I would suggest adopting it and add it as an "ann" repository in the 
pd-externals Github group: https://github.com/pd-externals 
 We can add you as a member.

With pd-lib-builder included, it would then be easy for more people to 
experiment and keep up to date. I would start by pulling the original commit 
history from IOhannes' SVN import repos: 
http://git.puredata.info/cgit/svn2git/libraries/ann.git/ 
. Then tag the last 
commit as version 1.0, if it doesn't hav one already. Next, bring in your 
changes and bump the version to 2.0 and we go from there.

One of the issues with Pd-extended was having such a large number of externals 
(which is great!), but slowly losing maintainers of many of them (which is hard 
for a small number of devs to deal with). With this transition to deken, we're 
seeing which externals people really want to keep up, so the code gets 
resurrected and the work gets distributed. This is a healthy sign for any 
external :)

> Any thoughts on this? Is there another neural net package for Pd that I'm
> totally ignorant of? A more current version of [ann] using FANN 2.0 that I
> just didn't come across in my searches?


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



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