[PD] Several questions about Gem and Pd vanilla (Mac OS X 10.13)

2020-06-08 Thread Dudley Brooks
Many of the answers I find online are not dated, so I'm not sure what 
the most recent info is.


(1) Is there an information source which is guaranteed to be the most 
up-to-date for Pd, and similarly for Gem?


(2) Is it true that Gem will only work with 32-bit versions of Pd? Or is 
that a now-outdated version of Gem?


(3) What settings do I use to make sure that Gem is found by any Pd 
patch opened by clicking on it or by clicking on the Pd app and then 
opening the patch from Pd?


or

(4) If I don't do (3), what do I include in a Pd patch to make sure the 
patch loads Gem?


Thanks.  Newbie to Gem, still somewhat newbie to Pd.



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


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread Christof Ressi

this breaks th eexpectations of cmdline processing (a separation between
options with arguments (e.g. '-a "1 2 3"') and 'just arguments"
("patch1.pd patch2.pd").

Agreed.

or should it be the other way round?

pd -args 'foo bar' -open "patch1.pd" -open "patch2.pd"

I tend to agree. It's also easier to parse.


it has the advantage that you can pass the same arguments to multiple
(or all) patches.
it also makes it quite easy to keep compatibility with the "the rest of
the arguments are files" paradigm:

pd -args 24 foo.pd bar.pd


Ugh... stateful command line options are ugly. What if you *don't* want 
to pass the arguments to subsequent patch files? I'd rather restrict the 
'-args' option to a single patch. But I'm not sure how to properly apply 
this to patch files provided as "just arguments". Maybe only allow it 
for patches opened with "-open"?


Christof

On 08.06.2020 20:52, IOhannes m zmölnig wrote:

On 6/8/20 5:49 PM, Christof Ressi wrote:

The thing is that we can load more than one patch. I think something
like this could work:

pd patch1.pd -a "1 2 3" patch2.pd -a "foo bar"

But we could move the bikeshedding to GitHub ;-)
https://github.com/pure-data/pure-data/issues/1058



actually i think that a mailinglist is much better suited for the
bikeshedding tour.

at least for me, i tend to apply a " closed-for-me" tag to all those
issues that have a very high noise-to-signal ratio (and there are quite
a couple of those).
the non-threaded nature of the issues makes it virtually impossible to
keep track of divergent opinions.

so:

pd patch1.pd -a "1 2 3" patch2.pd -a "foo bar"

urgh, no.
this breaks th eexpectations of cmdline processing (a separation between
options with arguments (e.g. '-a "1 2 3"') and 'just arguments"
("patch1.pd patch2.pd"). i think this separation is quite universal in
un*x like environments, and i don't see any compelling reason to
actually break it.

o a more consistent way would be:

pd -open patch1.pd -args "1 2 3" -open "patch2.pd" -args "foo bar"

or should it be the other way round?

pd -args 'foo bar' -open "patch1.pd" -open "patch2.pd"

the inspiration for this is the dollar-expansion in message-boxes.

it has the advantage that you can pass the same arguments to multiple
(or all) patches.
it also makes it quite easy to keep compatibility with the "the rest of
the arguments are files" paradigm:

pd -args 24 foo.pd bar.pd


gsamdr
IOhannes


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


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread IOhannes m zmölnig
On 6/8/20 5:49 PM, Christof Ressi wrote:
> The thing is that we can load more than one patch. I think something
> like this could work:
> 
> pd patch1.pd -a "1 2 3" patch2.pd -a "foo bar"
> 
> But we could move the bikeshedding to GitHub ;-)
> https://github.com/pure-data/pure-data/issues/1058
> 


actually i think that a mailinglist is much better suited for the
bikeshedding tour.

at least for me, i tend to apply a " closed-for-me" tag to all those
issues that have a very high noise-to-signal ratio (and there are quite
a couple of those).
the non-threaded nature of the issues makes it virtually impossible to
keep track of divergent opinions.

so:
> pd patch1.pd -a "1 2 3" patch2.pd -a "foo bar"

urgh, no.
this breaks th eexpectations of cmdline processing (a separation between
options with arguments (e.g. '-a "1 2 3"') and 'just arguments"
("patch1.pd patch2.pd"). i think this separation is quite universal in
un*x like environments, and i don't see any compelling reason to
actually break it.

o a more consistent way would be:
> pd -open patch1.pd -args "1 2 3" -open "patch2.pd" -args "foo bar"

or should it be the other way round?
> pd -args 'foo bar' -open "patch1.pd" -open "patch2.pd"

the inspiration for this is the dollar-expansion in message-boxes.

it has the advantage that you can pass the same arguments to multiple
(or all) patches.
it also makes it quite easy to keep compatibility with the "the rest of
the arguments are files" paradigm:
> pd -args 24 foo.pd bar.pd


gsamdr
IOhannes



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


Re: [PD] Pass arg to Pd via terminal - Test Suite

2020-06-08 Thread Jack
However, cool to have tests in Pd ;)
For the name : Pure DAT (Pure Data Auto Tests).
Too close to Pure Data ? Sure !
++

Jacj



Le 08/06/2020 à 17:55, Jack a écrit :
> For french people, after "pd", we have "pedant" :D
> I love !
> https://en.wiktionary.org/wiki/p%C3%A9dant
> ++
> 
> Jack
> 
> 
> 
> Le 08/06/2020 à 17:40, Christof Ressi a écrit :
>> Big thumps up for test suits! BTW, IOhannes has already been working on
>> a testing framework for Pd: https://git.iem.at/pd/pedant
>>
>> Christof
>>
>> On 08.06.2020 17:34, Mario Buoninfante wrote:
>>> Yap, in the end I put a [receive] in the patch as a workaround.
>>> I'll open a ticket on github then, I suppose this could be useful.
>>>
>>> Just to give you a bit more context here, the reason why I'm asking
>>> for this is because I'm prototyping a test suite for Pd - ie for
>>> "continuous integration' or simply for testing new features.
>>> I wanted to contribute a bit more to the cause and since this seems to
>>> be something we're missing atm, I thought I could spend some time on this.
>>> It would be great to have some scripts in place that allow us to check
>>> new and old features, to make sure things work fine on different OSs
>>> and machines and that we haven't broken anything while working on a
>>> new feature.
>>> As a starting point we could have Pd users running the suite on their
>>> machine and share the logs/results.
>>> I'm prototyping something simple in Lua simple, that shouldn't require
>>> too much effort in terms of maintenance.
>>>
>>> I'll open a ticket on github and share more details there.
>>>
>>> Please, let me know if you have any thoughts/suggestions/questions.
>>>
>>> Cheers,
>>> Mario
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> https://lists.puredata.info/listinfo/pd-list
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
>>
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 




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


Re: [PD] Pass arg to Pd via terminal - Test Suite

2020-06-08 Thread Jack
For french people, after "pd", we have "pedant" :D
I love !
https://en.wiktionary.org/wiki/p%C3%A9dant
++

Jack



Le 08/06/2020 à 17:40, Christof Ressi a écrit :
> Big thumps up for test suits! BTW, IOhannes has already been working on
> a testing framework for Pd: https://git.iem.at/pd/pedant
> 
> Christof
> 
> On 08.06.2020 17:34, Mario Buoninfante wrote:
>> Yap, in the end I put a [receive] in the patch as a workaround.
>> I'll open a ticket on github then, I suppose this could be useful.
>>
>> Just to give you a bit more context here, the reason why I'm asking
>> for this is because I'm prototyping a test suite for Pd - ie for
>> "continuous integration' or simply for testing new features.
>> I wanted to contribute a bit more to the cause and since this seems to
>> be something we're missing atm, I thought I could spend some time on this.
>> It would be great to have some scripts in place that allow us to check
>> new and old features, to make sure things work fine on different OSs
>> and machines and that we haven't broken anything while working on a
>> new feature.
>> As a starting point we could have Pd users running the suite on their
>> machine and share the logs/results.
>> I'm prototyping something simple in Lua simple, that shouldn't require
>> too much effort in terms of maintenance.
>>
>> I'll open a ticket on github and share more details there.
>>
>> Please, let me know if you have any thoughts/suggestions/questions.
>>
>> Cheers,
>> Mario
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 




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


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread Christof Ressi
The thing is that we can load more than one patch. I think something 
like this could work:


pd patch1.pd -a "1 2 3" patch2.pd -a "foo bar"

But we could move the bikeshedding to GitHub ;-) 
https://github.com/pure-data/pure-data/issues/1058


Christof

On 08.06.2020 17:09, Dan Wilcox wrote:
Or Pd can recognize the "--" flag which disables command line parsing 
hereafter. I looked into this as it was helpful for debugging the 
sound file stuff and found it was an easy change to make. I just never 
formalized it for a PR etc.


On Jun 8, 2020, at 5:00 PM, pd-list-requ...@lists.iem.at 
 wrote:


Date: Mon, 8 Jun 2020 15:12:34 +0100
From: Sebastian Lexer >
To: Pd-List mailto:pd-list@lists.iem.at>>, 
Christof Ressi

mailto:i...@christofressi.com>>
Subject: Re: [PD] Pass arg to Pd via terminal
Message-ID: <5ef354dd-97bc-4cbc-bc3b-a1df8c93fcae@Spark>
Content-Type: text/plain; charset="utf-8"

I like this idea very much! Could there be an argument flag? e.g.

$ pd mypatch.pd -a 23

Basically like terminal commands in sox, where the flags apply to 
import and output files dependent on the placement, in PD it could 
work as flags for PD before and in between the filename(s) to be opened.



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


Re: [PD] Please keep deken package online

2020-06-08 Thread Roman Haefeli
On Mon, 2020-06-08 at 11:41 -0300, Alexandre Torres Porres wrote:
> 
> This is why I asked Roman if this idea is ok and I'm worried now that
> he won't like the idea to be forced to have a script download both
> the library AND the tutorial.

You make it sound like I have some authority. I don't mean to make that
impression. The only relevant point (IMHO) is my suggestion to leave
stuff that is released and used by people untouched. Why? To make life
easier for you and for ELSE users. And it is simply a suggestion. If
you disagree, that's fine. 

Please do not care about my script. It is really irrelevant in this
discussion.

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] Pass arg to Pd via terminal - Test Suite

2020-06-08 Thread Christof Ressi
Big thumps up for test suits! BTW, IOhannes has already been working on 
a testing framework for Pd: https://git.iem.at/pd/pedant


Christof

On 08.06.2020 17:34, Mario Buoninfante wrote:

Yap, in the end I put a [receive] in the patch as a workaround.
I'll open a ticket on github then, I suppose this could be useful.

Just to give you a bit more context here, the reason why I'm asking 
for this is because I'm prototyping a test suite for Pd - ie for 
"continuous integration' or simply for testing new features.
I wanted to contribute a bit more to the cause and since this seems to 
be something we're missing atm, I thought I could spend some time on this.
It would be great to have some scripts in place that allow us to check 
new and old features, to make sure things work fine on different OSs 
and machines and that we haven't broken anything while working on a 
new feature.
As a starting point we could have Pd users running the suite on their 
machine and share the logs/results.
I'm prototyping something simple in Lua simple, that shouldn't require 
too much effort in terms of maintenance.


I'll open a ticket on github and share more details there.

Please, let me know if you have any thoughts/suggestions/questions.

Cheers,
Mario


___
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] Pass arg to Pd via terminal - Test Suite

2020-06-08 Thread Mario Buoninfante
Yap, in the end I put a [receive] in the patch as a workaround.
I'll open a ticket on github then, I suppose this could be useful.

Just to give you a bit more context here, the reason why I'm asking for
this is because I'm prototyping a test suite for Pd - ie for "continuous
integration' or simply for testing new features.
I wanted to contribute a bit more to the cause and since this seems to be
something we're missing atm, I thought I could spend some time on this.
It would be great to have some scripts in place that allow us to check new
and old features, to make sure things work fine on different OSs and
machines and that we haven't broken anything while working on a new feature.
As a starting point we could have Pd users running the suite on their
machine and share the logs/results.
I'm prototyping something simple in Lua simple, that shouldn't require too
much effort in terms of maintenance.

I'll open a ticket on github and share more details there.

Please, let me know if you have any thoughts/suggestions/questions.

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


Re: [PD] Please keep deken package online

2020-06-08 Thread Alexandre Torres Porres
Em seg., 8 de jun. de 2020 às 11:52, Simon Iten 
escreveu:

> you see, the idea is to leave whatever there is untouched and upload new
> stuff.
> if you want to include your tutorial from now on, do it! but leave the old
> versions as they were…
>

Ok, I see! It didn't occur to me that merely replacing and adding a folder
to the same download would count as changing the version (or
history/whatever). For me it would just be the same download, same version,
with something "else" => a bundle pack. But I get the confusion now, and I
see the point! Leave it untouched, if creating a bundle pack, a new version
should be made.

I don't really agree at all, but fine... and, in fact, one of the things I
asked and suggested was to just put it back as it was... and I guess I'll
just do that and we can get this over with ;)

And by the way, I almost named the new version as a "release candidate",
the relevant breaking changes now are basically from the
new functionality inlet~ provides in 0.51-0, I can't see more changes I
could make but I'm leaving doors open. That is to say a final/stable
release is quite near and the idea is to keep it stable and NEVER delete
the final versions.

Anyway, thank you all for the inputs and the interest in my work.

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


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread Dan Wilcox
Or Pd can recognize the "--" flag which disables command line parsing 
hereafter. I looked into this as it was helpful for debugging the sound file 
stuff and found it was an easy change to make. I just never formalized it for a 
PR etc.

> On Jun 8, 2020, at 5:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Date: Mon, 8 Jun 2020 15:12:34 +0100
> From: Sebastian Lexer mailto:s.le...@incalcando.com>>
> To: Pd-List mailto:pd-list@lists.iem.at>>, Christof 
> Ressi
>   mailto:i...@christofressi.com>>
> Subject: Re: [PD] Pass arg to Pd via terminal
> Message-ID: <5ef354dd-97bc-4cbc-bc3b-a1df8c93fcae@Spark>
> Content-Type: text/plain; charset="utf-8"
> 
> I like this idea very much! Could there be an argument flag? e.g.
> 
> $ pd mypatch.pd -a 23
> 
> Basically like terminal commands in sox, where the flags apply to import and 
> output files dependent on the placement, in PD it could work as flags for PD 
> before and in between the filename(s) to be opened.


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


Re: [PD] Please keep deken package online

2020-06-08 Thread Simon Iten


> On 8 Jun 2020, at 16:41, Alexandre Torres Porres  wrote:
> 
> Yup, I understand it all, and I've been trying to say my idea was to replace 
> that download (beta 27), reupload it, but containing my live electronics 
> tutorial with it. It seems this is not clear somehow, so, again, I wanted to 
> take it down and put it back like that, and then it didn't work. 

you see, the idea is to leave whatever there is untouched and upload new stuff.
if you want to include your tutorial from now on, do it! but leave the old 
versions as they were…

it is not about what is there or who needs it. it is about the fact that it is 
nice and sometimes even mandatory to download something exactly as it was when 
first used/released. so there is really no point in you taking it down and 
uploading it again with something included that was not there before. just 
leave the old stuff there for reference/history whatever. see it as a 
“historical” documentation of your work. don’t change history man! :-)___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] Please keep deken package online

2020-06-08 Thread Christof Ressi
and I've been trying to say my idea was to replace that download (beta 
27), reupload it, but containing my live electronics tutorial with it. 
It's not about beta 27, it's about *any* "else"-release. Some projects 
might depend on beta 24, some might need beta 13. Just don't delete old 
releases, that's all people are asking. (I'm not talking about replacing 
a broken upload, that is totally ok, of course)


How you package "else" and your tutorial is not related to the issue at 
hand (which is: "Please keep deken package online").


Christof

On 08.06.2020 16:41, Alexandre Torres Porres wrote:
Yup, I understand it all, and I've been trying to say my idea was to 
replace that download (beta 27), reupload it, but containing my live 
electronics tutorial with it. It seems this is not clear somehow, so, 
again, I wanted to take it down and put it back like that, and then it 
didn't work.


Yes, I was also in the process of getting a new release ready and 
upload it too, but I did this first and it didn't work, and I didn't 
know what to do with the new release as well. I tried many things in 
the last few days and it wasn't my intent to not have a single working 
version of else in deken available. I'm still trying to see if I want 
to do works or not. So don't assume what's in deken is what I want to 
be there, I said that it's a mess. I'm testing things and I haven't 
officially released the new version yet.


> Newest version appears on top in Deken. Right now. Deken provides 
the ELSE library only for two architectures.


As I said, you shouldn't consider what's in deken. For instance, the 
two downloads you mentioned have been deleted for quite a while. You 
can't get them. I'm waiting to see if the upload I made almost 24h ago 
will work as I intend.


I offered to put the last version back as it was if you needed right 
away, that's all.


And what exactly is my idea? To have a download from deken that 
includes both my library and my tutorial and that unpacks it into two 
separate folders from a single click. Oh, but one may only want the 
else library and don't care at all about the tutorial. Well, I dunno, 
what do you think? Feedbacks are welcome. I figure you can just delete 
that folder. And I also think it's a bit confusing and polluted if you 
have too many options, get only the library, only the tutorial or 
both... I'm hoping to have and manage only a single standard. But 
feedbacks are welcome.


This is why I asked Roman if this idea is ok and I'm worried now that 
he won't like the idea to be forced to have a script download both the 
library AND the tutorial.


cheers




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


Re: [PD] Please keep deken package online

2020-06-08 Thread Alexandre Torres Porres
Yup, I understand it all, and I've been trying to say my idea was to
replace that download (beta 27), reupload it, but containing my live
electronics tutorial with it. It seems this is not clear somehow, so,
again, I wanted to take it down and put it back like that, and then it
didn't work.

Yes, I was also in the process of getting a new release ready and upload it
too, but I did this first and it didn't work, and I didn't know what to do
with the new release as well. I tried many things in the last few days and
it wasn't my intent to not have a single working version of else in deken
available. I'm still trying to see if I want to do works or not. So don't
assume what's in deken is what I want to be there, I said that it's a mess.
I'm testing things and I haven't officially released the new version yet.

> Newest version appears on top in Deken. Right now. Deken provides the
ELSE library only for two architectures.

As I said, you shouldn't consider what's in deken. For instance, the two
downloads you mentioned have been deleted for quite a while. You can't get
them. I'm waiting to see if the upload I made almost 24h ago will work as I
intend.

I offered to put the last version back as it was if you needed right away,
that's all.

And what exactly is my idea? To have a download from deken that includes
both my library and my tutorial and that unpacks it into two separate
folders from a single click. Oh, but one may only want the else library and
don't care at all about the tutorial. Well, I dunno, what do you think?
Feedbacks are welcome. I figure you can just delete that folder. And I also
think it's a bit confusing and polluted if you have too many options, get
only the library, only the tutorial or both... I'm hoping to have and
manage only a single standard. But feedbacks are welcome.

This is why I asked Roman if this idea is ok and I'm worried now that he
won't like the idea to be forced to have a script download both the library
AND the tutorial.

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


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread Sebastian Lexer
I like this idea very much! Could there be an argument flag? e.g.

$ pd mypatch.pd -a 23

Basically like terminal commands in sox, where the flags apply to import and 
output files dependent on the placement, in PD it could work as flags for PD 
before and in between the filename(s) to be opened.

Sebastian
On 8 Jun 2020, 14:54 +0100, Christof Ressi , wrote:
> Ah, that's an interesting idea. Unfortunately, your proposed syntax wouldn't 
> work because any arguments after the flags are treated as patch files, so in 
> your case Pd would try to open "mypatch.pd" and "23".
> Top level patches usually don't use creation arguments because it is not 
> really possible to provide them with the current opening mechanism. But I 
> totally see how this could be useful. It would need some surgery in Pd, 
> though. Feel free to open an issue on GitHub!
> In the meantime, you can have a wrapper patch with a receiver which 
> dynamically creates the actual patch with the desired creation arguments.
> Christof
> On 08.06.2020 15:23, Mario Buoninfante wrote:
> > Hi Jack,
> >
> > Thanks for your help. That's great but is not exactly what I'm looking for.
> > In my previous email I missed an important bit, what I'd like to do is pass 
> > an arg to a specific patch.
> > Something like
> >
> > > pd mypatch.pd 23
> >
> > and then in "mypatch" I have [$1] that is now 23.
> >
> > Cheers,
> > Mario
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread Christof Ressi
Ah, that's an interesting idea. Unfortunately, your proposed syntax 
wouldn't work because any arguments after the flags are treated as patch 
files, so in your case Pd would try to open "mypatch.pd" and "23".


Top level patches usually don't use creation arguments because it is not 
really possible to provide them with the current opening mechanism. But 
I totally see how this could be useful. It would need some surgery in 
Pd, though. Feel free to open an issue on GitHub!


In the meantime, you can have a wrapper patch with a receiver which 
dynamically creates the actual patch with the desired creation arguments.


Christof

On 08.06.2020 15:23, Mario Buoninfante wrote:

Hi Jack,

Thanks for your help. That's great but is not exactly what I'm looking 
for.
In my previous email I missed an important bit, what I'd like to do is 
pass an arg to a specific patch.

Something like

> pd mypatch.pd 23

and then in "mypatch" I have [$1] that is now 23.

Cheers,
Mario


___
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] Pass arg to Pd via terminal

2020-06-08 Thread Mario Buoninfante
Hi Christof,

Just read your email, thanks guys for your help!


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


[PD] Pass arg to Pd via terminal

2020-06-08 Thread Mario Buoninfante
Hi Jack,

Thanks for your help. That's great but is not exactly what I'm looking for.
In my previous email I missed an important bit, what I'd like to do is pass
an arg to a specific patch.
Something like

> pd mypatch.pd 23

and then in "mypatch" I have [$1] that is now 23.

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


Re: [PD] Can someone build midifile for mac and linux?

2020-06-08 Thread IOhannes m zmölnig
On 6/7/20 5:09 PM, João Pais wrote:
> Hi list,
> 
> Martin Peach has released a new version of midifile. But since in the
> present situation he's not able to get to his computers, the binaries
> for the mac and linux versions can't be built and uploaded to deken.

there's so many continuous-integration services (CI) that hook into git
and which make automatic building of externals much easier.

e.g. for most of my externals i have a setup that whenever i push a new
change to my respository, it will be recompiled from scratch on
linux/amd64, linux/i386, linux/armhf (raspberry pi), linux/arm64,
windows/amd64, windows/i386 and darwin/amd64.
whenever i push a tag (aka: release), the binaries produced will also be
upload automatically to deken.

i only need physical access to a single machine (usually my trusty
linux/amd64 developer notebook; but that actually doesn't matter).


just a slight nudging to move from SVN to git :-)


gfmsad
IOhannes


PS: to be honest, none of this comes by magic; and instead required
setting up. it's just that in the git-ecosystem there are many more
actual options to do set up such an autobuild system than in the
svn-world or the cvs-era.



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


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread Christof Ressi

To expand on Jack's answer:

pd -send "foo baz; bar 1 2 3;"

This will send 'baz' to the receiver 'foo' and '1 2 3' to the receiver 
'bar'.


---

Here's a caveat for all Msys2 users on Windows: by default the Msys2 
terminal interprets messages starting with a forward slash as absolute 
file paths and prepends them with the Msys2 installation path. For example,


pd -send "/foo/bar 1 2 3"

will yield the following Pd error:

"C:/msys64/foo/bar: no such object"

Apparantly there's a way to turn this off with an environmental variable 
but I couldn't make it work. A possible workaround is to replace the 
first forward slash with a backslash:


pd -send "\foo/bar 1 2 3"

I once had been tearing my hear out for 1 hour, so I thought I'd better 
share this.


Christof

On 08.06.2020 14:32, Mario Buoninfante wrote:
On 08.06.2020 14:43, Jack wrote:

Hello Mario,

If you do :
$ pd --help

you should get a line with :
-send "msg..."   -- send a message at startup, after patches are loaded

++

Jack



Le 08/06/2020 à 14:32, Mario Buoninfante a écrit :

Hi,

Is it possible to pass arguments to Pd via terminal?
I know we don't have [stdin], but I was wondering if there is any other way.

Cheers,
Mario

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





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




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


Re: [PD] Pass arg to Pd via terminal

2020-06-08 Thread Jack
Hello Mario,

If you do :
$ pd --help

you should get a line with :
-send "msg..."   -- send a message at startup, after patches are loaded

++

Jack



Le 08/06/2020 à 14:32, Mario Buoninfante a écrit :
> Hi,
> 
> Is it possible to pass arguments to Pd via terminal?
> I know we don't have [stdin], but I was wondering if there is any other way.
> 
> Cheers,
> Mario
> 
> ___
> 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] Pass arg to Pd via terminal

2020-06-08 Thread Mario Buoninfante
Hi,

Is it possible to pass arguments to Pd via terminal?
I know we don't have [stdin], but I was wondering if there is any other way.

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


Re: [PD] Can someone build midifile for mac and linux?

2020-06-08 Thread Christof Ressi
Can someone upload it to Deken? Please always consider this option 
instead of e-mailing binaries ;-)


Christof

On 07.06.2020 22:02, João Pais wrote:
thanks all. I can't test these, but I assume that they work. 
apparently google is weird about attachments, but double-zipping 
tricks them.


Joao


i gave it a go…midifile.pd_darwin zipped inside a zipped folder :-)
works on my machine (mac os10.14.6).
the midifil- help has a problem, as the subpatch midifile_read is in 
vain looking for a file “wowo.mid”.


get it here: 
https://www.dropbox.com/s/n73968w7ej6d94w/midifile_darwin.zip


best
hans




Am 07.06.2020 um 19:25 schrieb William Brent :

Hmm, Gmail won't let me attach the Mac OS d_fat or pd_darwin here. 
I'll upload it later today and send you a link directly...


On Sun, Jun 7, 2020 at 1:07 PM William Brent 
 wrote:
Here's a build of midifile for Linux x86_64. Switching over to Mac 
OS now to get you that as well.


On Sun, Jun 7, 2020 at 11:37 AM João Pais  wrote:
Hi list,

Martin Peach has released a new version of midifile. But since in the
present situation he's not able to get to his computers, the binaries
for the mac and linux versions can't be built and uploaded to deken.

Would it be possible for someone with build powers to build these two
binaries? Here are the instructions sent by Martin:


You can get the code from the sourceforge repository:
svn checkouthttps://svn.code.sf.net/p/pure-data/svn/trunk pure-data-svn

I added the pd-lib-builder to the mrpeach directory in trunk/externals
so you just have to go there and type 'make' and see if it works.




If someone can send that to me, I can make them arrive to the 
correct place.


Best,
Joao




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



--
William Brent
www.williambrent.com

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

www.conflations.com


--
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





___
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] Please keep deken package online

2020-06-08 Thread Christof Ressi

Hi Alex,

just to sum up and emphasize what Roman has been saying: it's good 
practice to keep old releases around, because existing projects might 
depend on it. This is especially relevant in the case of "else", since 
there are breaking changes between beta versions.


Of course, you're free to tell users to get old releases from GitHub, 
but IMO this defeats the purpose of Deken.


As Roman mentioned, Deken shows the library in decreasing order of the 
version number. To get the most recent version, people just have to 
click the first entry.


So please consider not removing "else" releases from Deken in the future.

Christof

On 08.06.2020 09:27, Roman Haefeli wrote:

On Sun, 2020-06-07 at 19:34 -0300, Alexandre Torres Porres wrote:

The reason now, like I told you, is that I was/am trying to merge
into the same download the inclusion of my tutorial as a single combo
pack... so I put it down and tried to reupload but failed.

I see. What I'm actually suggesting is to do not touch already released
versions at all. If you make changes, then it should have a new version
and you should create a new release for this new version. At least that
is how I think releases should be handled and it seems already common
practice in Deken (and probably everywhere else in the software world).
Of course, you're free to do whatever you want with your software.


I've been asked before to keep old stuff and we discussed this
before, and I agreed it wouldn't hurt to keep not that many old
versions around. It gets to a point where things change so much and
so quickly that I just thought it was too much pollution to keep old
stuff around

I don't see the problem of pollution as long as you release new
versions with a higher version number (which you do). Newest version
appears on top in Deken. Right now, Deken provides the ELSE library
only for two architectures.


  so I had this policy. But the thing now is that I'm trying to do
this, and it got out of hand and over complicated, sorry.

But it seems now I'm being able to do it, let's see it in a day.

I can also just put the last version back if you give me a moment,

You don't have put stuff back solely for me.


and I'm still curious, how does your script work? Can you please tell
me more about your needs?

Actually, I shouldn't have mentioned my script. It's not relevant to
the discussion. My point is to not confuse regular users of the
library. I think they should have easy access to previous versions when
they develop their patches dependent on the library, for instance for
testing regressions.

My script simply downloads the library from a configured URL and
extracts it to the right place, nothing fancy  [1].


Actually, I'm also now concerned if this script will work with my
attempt to pack two folders into a single download for deken.

Again, you should not be concerned about my script, but about regular
users.


Roman


[1] I got many complaints about how hard is to install netpd, that's
why I'm trying to create standalone applications for macOS and Windows
with Pd+externals+netpd+instruments bundled. The script also downloads
and extracts the ELSE library.



___
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] Please keep deken package online

2020-06-08 Thread Roman Haefeli
On Sun, 2020-06-07 at 19:34 -0300, Alexandre Torres Porres wrote:
> The reason now, like I told you, is that I was/am trying to merge
> into the same download the inclusion of my tutorial as a single combo
> pack... so I put it down and tried to reupload but failed.

I see. What I'm actually suggesting is to do not touch already released
versions at all. If you make changes, then it should have a new version
and you should create a new release for this new version. At least that
is how I think releases should be handled and it seems already common
practice in Deken (and probably everywhere else in the software world).
Of course, you're free to do whatever you want with your software. 

> 
> I've been asked before to keep old stuff and we discussed this
> before, and I agreed it wouldn't hurt to keep not that many old
> versions around. It gets to a point where things change so much and
> so quickly that I just thought it was too much pollution to keep old
> stuff around

I don't see the problem of pollution as long as you release new
versions with a higher version number (which you do). Newest version
appears on top in Deken. Right now, Deken provides the ELSE library
only for two architectures. 

>  so I had this policy. But the thing now is that I'm trying to do
> this, and it got out of hand and over complicated, sorry. 
> 
> But it seems now I'm being able to do it, let's see it in a day. 
> 
> I can also just put the last version back if you give me a moment, 

You don't have put stuff back solely for me.

> and I'm still curious, how does your script work? Can you please tell
> me more about your needs?

Actually, I shouldn't have mentioned my script. It's not relevant to
the discussion. My point is to not confuse regular users of the
library. I think they should have easy access to previous versions when
they develop their patches dependent on the library, for instance for
testing regressions. 

My script simply downloads the library from a configured URL and
extracts it to the right place, nothing fancy  [1].

> Actually, I'm also now concerned if this script will work with my
> attempt to pack two folders into a single download for deken. 

Again, you should not be concerned about my script, but about regular
users.


Roman


[1] I got many complaints about how hard is to install netpd, that's
why I'm trying to create standalone applications for macOS and Windows
with Pd+externals+netpd+instruments bundled. The script also downloads
and extracts the ELSE library.




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