Re: [PD] 64-bit disis_munger for windows?

[Ivica Bukvic]

Probably, as it does not use the extended GUI struct callbacks. That said,
YMMV. Recompiling from source should guarantee its vanilla binary
compatibility. Hope this helps.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sun, Oct 20, 2019, 11:35 IOhannes m zmölnig  wrote:

> On 10/20/19 2:06 PM, Ivica Bukvic wrote:
> > I believe non-flext version is prepackaged with Purr-Data. Hope this
> helps.
>
> can that version be used with Pd-vanilla?
>
> dgamsr
> 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] 64-bit disis_munger for windows?

[Ivica Bukvic]

I believe non-flext version is prepackaged with Purr-Data. Hope this helps.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sat, Oct 19, 2019, 17:16 Eran Sachs  wrote:

> Hey folks,
> Keeping up with the theme of my previous post (I'm trying to get my old
> patch to work in a 64-bit world):
> Has anyone by any chance got disis_munger for 64-bit windows? There seems
> to be a linux version.
>
> Much appreciated,
> Eran
>
> ___
> 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] GPIO pi-extras

[Ivica Bukvic]

Oops, that should've read "since 2013..." Time flies by...

On Thu, May 16, 2019 at 9:41 AM Ivica Bukvic  wrote:

> FWIW, since 2016 Pd-L2Ork and its K12 mode come with a comprehensive set
> of objects for both GPIO and SPI (MCP3008) and more recently also
> mechatronics externals focused on solenoids and servos (to be uploaded in
> the next month or so--depending how soon my student gets the commit
> cleaned-up). The same are also in part based on the WiringPI library.
>
> https://github.com/pd-l2ork/pd/tree/master/l2ork_addons/raspberry_pi
>
> Best,
>
> Ico
>
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Institute for Creativity, Arts, and Technology
>
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
>
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
>
>
> On Thu, May 16, 2019 at 7:30 AM  wrote:
>
>> Hi,
>>
>> I wrote an external to read in values from a MCP3208 A/D converter IC
>> via SPI on the GPIOS of a Raspberry Pi
>>
>> https://github.com/HerrSteiner/wiringPD
>>
>> its based on PD-Wiring Pi by Jaime Oliver La Rosa and research on
>> diverse forum threads.
>>
>> Cheers,
>>
>> Malte
>>
>>
>>
>> ___
>> 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] GPIO pi-extras

[Ivica Bukvic]

Forgot to add, as far as I can tell they should also work with vanilla.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net



On Thu, May 16, 2019 at 9:41 AM Ivica Bukvic  wrote:

> FWIW, since 2016 Pd-L2Ork and its K12 mode come with a comprehensive set
> of objects for both GPIO and SPI (MCP3008) and more recently also
> mechatronics externals focused on solenoids and servos (to be uploaded in
> the next month or so--depending how soon my student gets the commit
> cleaned-up). The same are also in part based on the WiringPI library.
>
> https://github.com/pd-l2ork/pd/tree/master/l2ork_addons/raspberry_pi
>
> Best,
>
> Ico
>
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Institute for Creativity, Arts, and Technology
>
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
>
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
>
>
>
> On Thu, May 16, 2019 at 7:30 AM  wrote:
>
>> Hi,
>>
>> I wrote an external to read in values from a MCP3208 A/D converter IC
>> via SPI on the GPIOS of a Raspberry Pi
>>
>> https://github.com/HerrSteiner/wiringPD
>>
>> its based on PD-Wiring Pi by Jaime Oliver La Rosa and research on
>> diverse forum threads.
>>
>> Cheers,
>>
>> Malte
>>
>>
>>
>> ___
>> 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] GPIO pi-extras

[Ivica Bukvic]

FWIW, since 2016 Pd-L2Ork and its K12 mode come with a comprehensive set of
objects for both GPIO and SPI (MCP3008) and more recently also mechatronics
externals focused on solenoids and servos (to be uploaded in the next month
or so--depending how soon my student gets the commit cleaned-up). The same
are also in part based on the WiringPI library.

https://github.com/pd-l2ork/pd/tree/master/l2ork_addons/raspberry_pi

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net



On Thu, May 16, 2019 at 7:30 AM  wrote:

> Hi,
>
> I wrote an external to read in values from a MCP3208 A/D converter IC
> via SPI on the GPIOS of a Raspberry Pi
>
> https://github.com/HerrSteiner/wiringPD
>
> its based on PD-Wiring Pi by Jaime Oliver La Rosa and research on
> diverse forum threads.
>
> Cheers,
>
> Malte
>
>
>
> ___
> 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] [PD-announce] Purr-Data Google Summer of Code opportunity

[Ivica Bukvic]

Greetings fellow Pd enthusiasts,

As some of you may be already aware, ast year the Purr-Data (a.k.a.
Pd-L2Ork v2) was adapted to support native 64-bit operations. We are
pleased to report that Purr-Data was once again selected this year as one
of the GSoC projects. This means more opportunities to engage and help
further the platform. Ideas for this year are plentiful, ranging from core
infrastructure (C) development to patching and front-end development,
including porting Pd-L2Ork's K12 learning module that has seen its
utilization in dozens of Maker camps over the past 7 years.

If interested, please contact Jonathan and/or me to explore potential
projects and to discuss the next steps in the application process.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu

www.icat.vt.edu
www.performingarts.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
___
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] multiple instances of a patch forbidden in 0.49, why?

[Ivica Bukvic]

Pd-L2Ork offers -unique startup flag that leverages Tcl/Tk's ability to
share variables across multiple apps. By default it tries to open patches
in an existing instance to prevent newcomers who tend to open patches by
double-clicking on icons from opening multiple instances of Pd-L2Ork and
thereby getting confused by the existing patches (if any) not communicating
with the new one (e.g. via sends and received) or having two consoles. With
some minor modifications, this should  be also able to do the same per
patch  Please feel free to copy/port, as needed.

Best,

Ico


-- 
Ivica Ico Bukvic, D.M.A.
Interim Assoc. Dean, College of Liberal Arts and Human Sciences
Creative Technologies in Music
Director -- DISIS, L2Ork
ICAT Senior Fellow
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
liberalarts.vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sat, Sep 22, 2018, 17:30 Miller Puckette  wrote:

> I guess the least annoying of all would be to revery back to the way it
> was, and then to add an "open-unique" message to pd for anyone who wants
> this behavior (apparently not many do).
>
> cheers
> Miller
>
> On Sat, Sep 22, 2018 at 11:26:48PM +0200, Roman Haefeli wrote:
> > 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
>
>
>
> > ___
> > 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] what's up with "#" and iemgui labels (bug)?

[Ivica Bukvic]

Yes 1.x and by extension 2.x.

I haven't checked but am reasonably sure it handles those scenarios ok.

Best,

Ico


-- 
Ivica Ico Bukvic, D.M.A.
Creative Technologies in Music
Director -- DISIS, L2Ork, CTM
ICAT Senior Fellow
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net


On Mar 13, 2018 10:28, "Alexandre Torres Porres"  wrote:

2018-03-12 20:03 GMT-03:00 Ivica Ico Bukvic :

> This was fixed in pd-l2ork a while ago. Perhaps porting the patch may not
> be a bad idea?
>

you mean in pd-l2ork 1.0? With tcl? And what about the issue IOhannes
mentioned?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Fwd: Re: why not Purr Data?

[Ivica Bukvic]

Forgot to copy list...

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
-- Forwarded message --
From: "Ivica Bukvic" 
Date: Oct 2, 2017 23:06
Subject: Re: [PD] why not Purr Data?
To: "Roman Haefeli" 
Cc:



On Oct 2, 2017 14:07, "Roman Haefeli"  wrote:

On Mon, 2017-10-02 at 15:53 +, Jonathan Wilkes wrote:
> > Many of my patches that I developed on Pure Data don't run without
> > modification in Purr Data. Some crash at loading, some look
> graphically
> > weird
>
> Typically, "crashers" and "freezers" get fixed pretty quick in Purr
> Data.
>
> The only freezer I remember with one of your patches was due to a
> broken object triggering an infinite loop in your patch's [until]
> object. I'm
> pretty sure that was an alpha or beta version, and I'm pretty sure I
> fixed
> whatever object it was that wouldn't create.
>
> I don't see any other relevant crashers listed on the tracker:
>
> https://git.purrdata.net/jwilkes/purr-data/issues
>
> What am I missing?


Nothing and I am sure you'll fix anything quickly. I didn't mean at all
to doubt your sensible care about Purr Data. It's certainly well
maintained.

I haven't reported as it seemed too tedious work for not being easily
able to support Purr Data anyway. Many patches would require to move
sliders and other widgets inside GOP windows around for them to become
visible, which would make them invisible again in Pure Data and I can't
remember other things that are not bugs, but design decisions. For me,
supporting both of them is a lost case, so I decided for one.


This is why Pd-l2ork/Purr-Data has had for at least 2-3 years the -legacy
startup flag that ensures iemgui widgets are inconsistently offset to match
the vanilla behavior plus some other similarly inconsistent behaviors...


If supporting pure vanilla patches to their full extent would be a
stated goal of the Pure Data project, I'd have some incentive to report
stuff, but it seems it isn't.



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

Re: [PD] GUI freeze

[Ivica Bukvic]

This is likely dur to a buggy implementation of a particular widget
redrawing which may be a third-party widget. It may be also due to out of
sequence execution of commands in case the widget does not enqueue all it's
GUI commands like it should. One way pd-l2ork 1.0 dresses this which is an
ugly workaround but at least it prevents you from losing GUI in the middle
of a performance is to process all TCL commands using the try/catch command
(can't remember the right syntax). This way if a TCL command fails, the GUI
will remain responsive. It is possible this introduces an additional
overhead in terms of CPU usage even though I have not observed any.

Best,

Ico

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 23, 2017 08:08, "Roman Haefeli"  wrote:

>
> BTW, A friend of mine and me, we have been experiencing it on Linux and
> on Windows with versions Pd 0.46 - 0.48.
>
> Roman
>
> On Fre, 2017-09-22 at 16:11 +0200, Johnny Mauser via Pd-list wrote:
> > I have the same behaviour in Ubuntu 16.04 and pd 0.46
> >
> > The only workarround i found was to construct the gui in another
> > instance.
> >
> > Am 22.09.2017 3:14 nachm. schrieb "Roman Haefeli"  > >:
> > Hey all
> >
> > Apologies for a somewhat vague bug report about a hard to reproduce
> > issues (yeah, everybody loves those).
> >
> > I tend to create instruments for netpd with lots of visual feeback
> > (song position in sequencer, triggered notes, automated values,
> > meters). Sometimes during sessions with rather many instruments, it
> > happens what I (only half-correctly) call a GUI freeze. Sliders,
> > number
> > atoms, symbol atoms, radios etc. stop visually reflecting any change.
> > They still do send new values through their outlet, but are not
> > updated
> > visually, neither when manually changed or when sending new values
> > through inlet or send symbol. When it happens, it affects all GUI
> > widgets of all patches the running Pd instance. It usually happens
> > after an error is printed to the Pd console:
> >
> >  (Tcl) INVALID COMMAND NAME: invalid command name ".x88d5c68.c"
> > while executing
> > ".x88d5c68.c delete curve8cc3d94"
> > ("uplevel" body line 23)
> > invoked from within
> > "uplevel #0 $docmds"
> >
> >
> > Interestingly, when I minimize a canvas and unminimize (or switch
> > desktop away and back) it again, it all widgets display the current
> > values, though live changes are still not updated. Also not all
> > properties of the GUI widgets are affected. Label texts, label fonts,
> > background, foreground and label colors, also cnv dimensions and
> > similar things are still updated. Or in other words: Those aspects
> > that
> > work both ways (GUI -> pd and pd -> GUI) are affected, while the
> > supplemental features of the widgets that can't be controlled by
> > mouse
> > (pd -> GUI only) are not affected. The situation persists until I
> > restart Pd.
> >
> > That's again a vague statement, but I have the impression it got
> > slightly worse when switching from 0.47 to 0.48. I'm not able to
> > create
> > a simple patch that triggers the GUI freeze. However, I have saved
> > sessions that run reliably into this within minutes.
> >
> > Thanks for any thoughts on this.
> >
> > Roman
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> > tinfo/pd-list
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis
> > tinfo/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] purr data 2.1.1

[Ivica Bukvic]

1.0 will only be updated at this point in case there is major regression or
there is a demand to do so. All development will soon shift to 2.0 a.k.a.
Purr-Data. One thing that is still missing in 2.0 is the k12 mode sidebar
and customizations and some minor cosmetic changes. I am hoping to get to
this sometime this summer unless Jonathan beats me to it.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Mar 12, 2017 18:18, "Alexandre Torres Porres"  wrote:

> 2017-03-12 19:09 GMT-03:00 Jonathan Wilkes :
>
>>
>> There's a separate repo for pd-l2ork 1.0-- that's the one that uses
>> tcl/tk/tkpath for the GUI.  That codebase has been officially merged with
>> pd-l2ork 2.0 (which is what I call "Purr Data").  Official in the sense
>> that we've gone through and tried to make sure that we ported all changes
>> to pd-l2ork 1.0 during the time pd-l2ork 2.0 was being created.
>>
>
> So there's a pd-l2ork 1.0-- version that has the same features as the
> latest purr data (2.1.1) release? that's not quite clear to me yet.
>
> cheers
>
> ___
> 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] Fwd: [coll] bug

[Ivica Bukvic]

I am perfectly fine with that because I don't mind updating all my patches
to adapt them to this change. You will, however, find other users who won't
like this because they will need to update their patches, even though it
may be a matter of running a simple shell script.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Feb 1, 2017 11:37, "Alexandre Torres Porres"  wrote:

2017-01-29 17:53 GMT-02:00 Ivica Ico Bukvic :

> I also think unthreaded should be default to maintain determinacy in sync
> with Max,


2017-01-30 17:42 GMT-02:00 Roman Haefeli :

> Sounds like Max' [coll] is threaded


yep, it is threaded, so the idea it shouldn't be the default to be in sync
with max is wrong, if the idea is to be in sinc with max, than threaded
needs to be the default.


> it seems when using [coll] in Max, determinacy is lost, which was the main
> point people argued about.
>

I think there's an issue here regarding a difference between Max and Pd. In
Max, determinacy is actually usually lost, and people coming from the Max
perspective is used to dealing with that.

Another point is that the 3rd outlet of coll, which sends a bang, only
exists because of this loss of determinacy, since you can only rely on its
output to warn you that the file read is done. If Max were a determinant
environment, then there wouldn't be the need of this outlet at all.

Now, we're cloning this object, with its 3rd outlet and everything, and the
library is supposed to be fully compliant with max, that all adds up to the
case of making it default.

See, I'm working on its documentation right now, and if threaded is not the
default, this is kinda of what I'd have to say:

- careful when using coll in the default settings, as it can cause drop
outs for large files, unlike in max

- coll in the default setting is determinant, which makes its 3rd outlet
basically useless, going totally against its logic and purpose of
existence, as its only function is to signal the end os the action in an
indeterminant environment, as it is the case with max

- the default setting of coll is here just for the case where one is using
[trigger] to first send a read message into coll and send a bang or
whatever next only after the file read is complete, instead of relying on
the 3rd outlet of coll, which is how coll was built... so basically if one
is going against it design.

You see how confusing that is? Now, if threaded is the default and I'm to
document it, all I have to do is say:

- As in Max, this doesn't choke the audio and is indeterminant, so you need
to rely on its 3rd outlet.

Done...

Even though it adds a lot of noise, my compromise would be to have a
backwards compatibility flag (-unthreaded / "@threaded 0" or whatever),
where I can make a separate subpatch to explain all the issues involved. I
can then warn that it can cause audio chokes, and how it makes the 3rd
outlet pointless, and how it is not compliant with max, and I guess it only
serves, in the end, to warn and educate people to use this object
correctly.  I see much more advantage in fixing a patch that was incorrect
than consciously choosing to set the object to behave in an unthreaded way,
with many inconsistencies and an issue like potential drop outs.

If this is being argued just because of the issue of backwards compatibility
breakage, I'd like to point out that it is really far from being any major
issue in that respect, there is only a tiny change, in respect to just one
among dozens of  features.

It is much more related to a bug fix than anything else, and usually fixing
bugs do change the behaviour, of course. Looks like more of a discussion
related to "is it a bug or a feature"? Well, for me it is a bug, because
this so called "feature" is relying on bad practice (not using the 3rd
outlet, as you should), and if you rely on it in order for your patch work,
well, maybe you should just fix your patch, instead of relying on a mistake.

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

Re: [PD] [delwrite~], or "what Pd operations are/should be realtime?"

[Ivica Bukvic]

For clear, I can imagine having a second empty memory buffer being created
while delay continues to use the populated one until the memory allocation
is complete. At that point a simple change in the pointer should suffice,
after which the old buffer gets trashed. This would break determinacy, so
perhaps a separate argument could be used to enable this option in which
case the object could get another outlet that sends a bang when the
procedure is complete.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Nov 22, 2016 00:07, "Matt Barber"  wrote:

> Hi list; thanks for a wonderful PdCon (to Stevens and NYU people
> especially).
>
> I had a quick chat with Miller after the "future of Pd" discussion. I told
> him there is one feature I've heard Pd users ask for many times: a "clear"
> method for [delwrite~]. A [delwrite~] resize method is something I've heard
> brought up a number of times as well, but I didn't mention it.
>
> Each of these has a runtime cost that could disrupt the realtime dsp
> calculation. Clearing a [delwrite~] is a linear-time operation, and for
> long delay lines it could cause audio dropouts; resizing is more
> problematic because it's not clear what to do with samples already in the
> delay line – probably it would need to be cleared as well, which would take
> even more time (although there is already an indirect resize function when
> sample rate is changed).
>
> On the other hand, Pd arrays can be resized and cleared (const 0) ad
> libitum, which is more or less the same operation. We usually tell users
> 'do this at your own risk when computing audio.'
>
> So what is the main difference? I think it's that [delwrite~] is a tilde
> object that is supposed not to cause dropouts on its own. If clearing it
> could cause a dropout, there are reasons for thinking of that as a bug
> rather than simply a risk.
>
> Is there a compromise procedure? We could add an option to spread the
> clearing out over time. For instance "clear 5000" would mean "clear the
> delay line over the next 5000 ms." A second argument would let the user
> choose whether to preferentially preserve the most recent samples or the
> oldest samples. Given only a time argument, default would be to preserve
> oldest samples (less work has to be done overall since the write pointer
> would also be filling the line with zeroes). Without a time argument (i.e.
> "clear" with no arguments), the default would be to clear it immediately
> with the understanding that there could be a possible dropout.
>
> A broader topic for another time would be "what Pd operations are/should
> be realtime, and which are best at load time?"
>
> Thoughts?
>
> Matt
>
> ___
> 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] Purr Data Beta 4

[Ivica Bukvic]

There is a build of pd-l2Ork for RPi3 (that's what we used at the PdCon
workshops)--I just need to post it.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Nov 19, 2016 08:29, "Ingo"  wrote:

> Could it be possible that the RPi3 has problems with the L2Ork
> instructions?
>
> The RPi3 uses a ARMv8 vs. the ARM6 of the RPi2.
>
>
>
> Ingo
>
>
>
> *From:* Jonathan Wilkes [mailto:jancs...@yahoo.com]
> *Sent:* Wednesday, November 16, 2016 5:42 PM
> *To:* Ingo
> *Cc:* pd-list@lists.iem.at
> *Subject:* Re: [PD] Purr Data Beta 4
>
>
>
> > No Raspbian binaries?
>
>
>
> Well, I'll try.  But my rpi2 tends to reset in the middle of a build.
> (Seems to be a problem
>
> with the touchscreen I have it hooked to...)
>
>
>
>
>
> > BTW, are there instructions for installing on Raspbian?
>
> > I tried to install Beta3 but it wouldn’t do it. Probably some
> dependencies are missing …
>
> *> (I forgot the error message - I need to try again to get the error
> message.)*
>
>
>
> > The instructions from L2Ork didn’t work either ...
>
> > (probably because they are not updated to the current Raspbian or the
> RPi3)
>
>
>
> To build I use the l2ork instructions, and I don't get any errors.  But
> it's still
>
> possible to get a successful build where some of the externals didn't
> compile
>
> properly.  I'm in the process of solidifying the state of the external
> libs with a
>
> little Pd-based test suite, so that should help things along some.
>
>
>
> -Jonathan
>
>
>
> > Ingo
>
>
>
>
>
> *From:* Pd-list [mailto:pd-list-boun...@lists.iem.at
> ] *On Behalf Of *Jonathan Wilkes via Pd-list
> *Sent:* Tuesday, November 15, 2016 3:36 AM
> *To:* Pd-List
> *Subject:* [PD] Purr Data Beta 4
>
>
>
> Purr Data Beta 4 is here:
>
> https://git.purrdata.net/jwilkes/purr-data-binaries/tree/master
>
>
>
> * automatic translations based on system local (thanks to Albert Gräf)
>
> * German translations (thanks to Albert Gräf)
> * added ds tutorial for field parameters
> * fixes for automatic multi-connection behavior (thanks to Albert Gräf)
> * fixes for preset_hub/node (thanks to Albert Gräf)
> * fix for resizing [cnv] with mouse
> * fixes for OSX Makefile (thanks to Christian Frisson)
> * add feature to open files in the running instance
> * port unauthorized/grid
> * various other bugfixes
>
>
>
> -Jonathan
>
>
>
> ___
> 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] Fwd: [PD-dev] [pure-data:bugs] #1273 feature request - paste from clipboard

[Ivica Bukvic]

Pd-l2Ork supports universal clipboard but is somewhat limited by the Tcl/Tk
idiosyncrasies, like having to start the application and then copying
because the preexisting system clipboard is not actually recognized by the
toolkit. It also supports pasting actual text from the patches into an
existing patch which I suspect is the inverse of what you're speaking of.
However, if you paste something incomplete it may result in a crash for
which I have not figured it a workaround. As a perhaps pointless courtesy,
if you do paste something that compromises Pd-L2Ork,  it will give you one
last message in the console before it crashes and burns and will let you
know what is the reason for the pending crash.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Oct 18, 2016 11:44, "Alexandre Torres Porres"  wrote:

>
> 2016-10-18 5:47 GMT-02:00 IOhannes m zmoelnig :
>
>> On 2016-10-18 07:41, Alexandre Torres Porres wrote:
>> > how hard would this be?
>>
>>
>> dropsuite.
>>
>
> that looks great, but the description is not giving me the idea that you
> can paste a text as a pd patch, so it does do it, right?
>
> cheers
>
>
> ___
> 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] purr data beta1

[Ivica Bukvic]

Not yet. I need to carve out some time to learn the packaging.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Oct 2, 2016 2:07 PM, "Jonathan Wilkes via Pd-list" 
wrote:

> > On 10/02/2016 04:11 PM, Jonathan Wilkes via Pd-list wrote:
>
>
>
> >> All I find is libjack-jack2-0 in the list of "Depends:" values.
>
>
> > which begs to break.
>
> > i thought that pd-l2ork switched to automatic shlibdeps  awhile ago?
>
> I don't know.  Ivica?
>
> -Jonathan
>
> gfmasre
> 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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Ivica Bukvic]

That was eons ago. You now have also arch Linux packages thanks to Albert.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 30, 2016 15:38, "patrice colet"  wrote:

>
>
> Le 30/09/2016 à 20:47, Ivica Ico Bukvic a écrit :
>
>>
>>
>>
>> On 9/29/2016 6:04 PM, patrice colet wrote:
>>
>>>
>>>
>>> Le 29/09/2016 à 23:45, Jonathan Wilkes a écrit :
>>>
 > Not sure Purr Data will replace anything since sources aren't
 available

 https://git.purrdata.net/jwilkes/purr-data



 Btw-- successfully building for Windows, OSX, and Gnu/Linux was by _far_
 the most time-consuming part of this project.


>>> I'm trying it right now with hoping that it won't crash when jackd is
>>> stopped, that's the main reason for me to consume time on it.
>>>
>>
>> Did you try pd-l2ork (assuming you have access to Linux)? I thought I
>> fixed this a while ago.
>>
>
> Yes I did, I even planned to make a better archlinux package but I had
> problems with managing externals, and chosen to stay on vanilla since deken
> came out.
>
>
>>
>>>
>>> ___
>>> 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/li
>> stinfo/pd-list
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] purr data beta1

[Ivica Bukvic]

I think it can only be spiritual successor if you believe it to be one in
part because its philosophy is different. What I said originally was that I
had no explicit intentions on replacing extended in part because I was not
sure what was its roadmap and whether it had a chance of being developed
further. In other words, I never denied its capacity to replace extended
but also did not want to assert that in any kind of authoritative way. Hope
this helps!

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 29, 2016 14:52, "Dan Wilcox"  wrote:

In this light, is Purr Data the spiritual successor for Pd-Extended? As I
recall in previous discussions, y'all were explicit that Pd-L2Ork was not.

This question is not meant as a slight in any way. I’m just curious how
this new project fits within your goals and the Pd community at large.


Dan Wilcox
@danomatika 
danomatika.com
robotcowboy.com

On Sep 29, 2016, at 12:29 PM, pd-list-requ...@lists.iem.at wrote:

*From: *Alexandre Torres Porres 
*Subject: **Re: [PD] purr data beta1*
*Date: *September 29, 2016 at 11:21:49 AM MDT
*To: *"pd-list@lists.iem.at" 


In short: *A Game Changer!*

2016-09-29 13:06 GMT-03:00 Ivica Ico Bukvic :

> Purr-Data is a GUI rewrite for Pd-L2Ork which has over 1,500
> patches/bugfixes/improvements over vanilla/extended. Its design principle
> is centered around nimble distributed development which may (and already
> does) include improvements in core behavior. Hope this helps!
>
> Best,
>
> Ico
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [coll] bug

[Ivica Bukvic]

Instead of outright removing the feature for all platforms when it works on
2 out of 3 them, you could disable building it on Windows as it is very
much useful on other platforms that support POSIX threads. There are
wrappers out there for this purpose, and IIRC differences between native
Windows threads and pthreads are not that great. So a fix, while it is
likely more time-consuming than deleting the code, in this case should not
be that much harder to do.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 18, 2016 08:15, "Alexandre Torres Porres"  wrote:

> 2016-09-17 11:03 GMT-03:00 Ivica Bukvic :
>
>> Is this fix Windows specific or is it gone on all platforms?--
>>
> the latest build, 02beta3 has the threaded version gone, but it is only
> available for windows - though the help file still mentions the thread flag
>
> ___
> 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] [coll] bug

[Ivica Bukvic]

Is this fix Windows specific or is it gone on all platforms?

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 17, 2016 13:20, "Fred Jan Kraan"  wrote:

> Hi Oliver,
>
> There is a cyclone-v0.2beta3 for Windows available. The error message is
> gone (tested), but there is no thread functionality anymore.
>
> Greetings,
>
> Fred Jan
>
> > hi, list !
> >
> > i recently ran into a bug when i used the "coll" object from the BETA
> > cyclone library.
> >
> > simply put: when i create a coll object and quit PD, it throws a
> > Microsoft Visual C++ Runtime Error (see image).
> >
> > example patch is attached.
> >
> >
> > the object seems to work though, as long as PD is running. only the 3rd
> > outlet (bang when file read) doesn't work.
> >
> >
> > i downloaded the cyclone 0.2 beta package with deken.
> > the older pd-extended version (also from deken) works fine.
> >
> >
> > PD 0.47-2, Windows 7 64 bit
> >
> >
> > did anybody experience this as well ?
> >
> >
> >
> > best
> >
> > oliver
> >
> >
> >
> >
> > ___
> > 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] bendin bug (?)

[Ivica Bukvic]

Couldn't you simply open older patches with an older version of pd? Even
gcc over time requires changes to the source that uses deprecated API.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net

On Sep 12, 2016 08:22, "IOhannes m zmoelnig"  wrote:

> On 2016-09-12 11:25, Derek Kwan wrote:
> > i think it'd be fine to outright change one and
> > break backwards compat
>
> that's most likely because you don't have accumulated a lot of patches
> that rely on the old behaviour.
>
> fgmasdr
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] PdCon16 -- 5th International Puredata Convention @ NYU

[Ivica Bukvic]

Very cool!

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Jun 5, 2016 2:24 AM, "Jaime Oliver"  wrote:

> Dear All,
>
> If we take Miller Puckette's 1996 publication* as the beginning of Pd,
> then 2016 marks its 20th anniversary. To celebrate this birthday with
> Miller and the Pd Community we’d like to organize the 5th Pure Data
> Convention in New York City on November 17-20, 2016.
>
> There are still a lot of details that we’re working out and a proper call
> will follow soon, but in the meantime, we want everyone to save the dates
> and include the convention in your travel plans as well as to prepare
> proposals for papers, workshops, and concerts.
>
> We’re assembling a team at NYU’s Waverly Labs to host PdCon in the Music
> Department @ GSAS, with the support of the Washington Square Contemporary
> Music Society and New Blankets, and in coordination with local institutions
> like the Stevens Institute of Technology.
>
> Looking forward to seeing you in New York.
>
> All the best,
>
>
> Jaime Oliver
>
>
> * Puckette, Miller. "Pure Data: another integrated computer music
>  environment." Proceedings of the Second Intercollege Computer Music
>  Concerts (1996): 37-41.
>
>
> ___
> 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] [L2Ork-dev] new alpha release of pd-l2ork

[Ivica Bukvic]

Pd-L2Ork beta release is now available (64bit version only for the time
being--final release will have both 32bit and 64bit). Please test and
report bugs. Thank you.

http://l2ork.music.vt.edu/data/pd/pd-l2ork-x86_64-20160530.deb (27MB 64bit
Ubuntu deb)

Best,

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

Re: [PD] [L2Ork-dev] new alpha release of pd-l2ork

[Ivica Bukvic]

OK, new version is uploading now (git is already updated). This should
definitely address the text problem. I still need to figure out what is
wrong with the array object. Can you please check that has been fixed as
well or send me a patch that induces a crash? I do see still some
extraneous errors both from text and the array objects I will need to
investigate. Thank you.

On Thu, May 26, 2016 at 8:31 AM, Albert Graef  wrote:

> Hi Ico,
>
> On Thu, May 26, 2016 at 7:26 AM, Ivica Bukvic  wrote:
>
>> New version containing bunch of ports from vanilla and fixes to the
>> issues reported by the users over the past several weeks is now out and I
>> could really use some feedback in terms of testing. New features/fixes
>> include:
>>
>
> thanks for all the amazing new stuff! :)
>
> I didn't do exhaustive testing of the new and updated features yet, but
> since you've asked for feedback, here goes. All testing done with latest
> revision (4f92725) on Manjaro (Arch).
>
> On the bright side, 'sys_fopen' appears to work fine, so ticket #34 can be
> closed.
>
> 'clone' also appears to work fine, AFAICT (only played around a little
> with the help patch).
>
> On the not so bright side, I can get neither 'array' nor 'text' to work.
> The corresponding help patches just make pd-l2ork segfault as soon as I try
> to open them. Even a rather minimal test patch (bug.pd, attached) makes
> pd-l2ork segfault. I've also attached a gdb backtrace from 'array'
> (pd-l2org-bt.txt) so that you can try to make sense of this ('text'
> produces basically the same backtrace). I should add that the same objects
> work fine in vanilla for me, so it's probably *not* an Arch- or
> cpu-specific issue.
>
> The last thing is from my personal wishlist. While you're at it, could
> 'menu_openfile' please be added back to pd-l2ork? Suggested patch to
> pd_menus_SHORT.tcl attached. I'm not sure how many external writers are
> using this, but I certainly do as it provides a convenient way to open the
> programs associated with Pure and Faust externals in Pd. I'm currently
> applying this patch in the Arch package, but it would be nice to have this
> working again on Debian/Ubuntu as well. Shouldn't do much harm either since
> it's in its own namespace. :-)
>
> Albert
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email:  aggr...@gmail.com
> WWW:https://plus.google.com/+AlbertGraef
>
> ___
> L2Ork-dev mailing list
> l2ork-...@disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] new alpha release of pd-l2ork

[Ivica Bukvic]

All,

New version containing bunch of ports from vanilla and fixes to the issues
reported by the users over the past several weeks is now out and I could
really use some feedback in terms of testing. New features/fixes include:

New objects:
text
array
oscparse
oscformat
bob~
others I cannot think of right now?


Updated objects:
netsend
netreceive
declare
merged expr


Bug fixes (all need testing):
cycling's sys_fopen compatibility
disis_gpio and WiringPi library regression where one could not create more
than one object
autotune~ segfault
Ubuntu 16.04 and recent Debian support (should also support older versions)
Build script improvements


Updated internals:
path loading (partial implementation)
new loadbang implementation


Outstanding issues:
A few spots with Jonathan's additions that appear to collide with recent
changes in the vanilla codebase. (Jonathan, please look at g_readwrite.c)


At this point, I would really appreciate your feedback. I am not yet
familiar with the many of the introduced features and bugfixes to be able
to judge their proper operation. Current build is for 16.04 64bit Ubuntu
and while it may work on other flavors, YMMV. Thank you.

To download unofficial alpha use the following link:
http://l2ork.music.vt.edu/data/pd/pd-l2ork-x86_64-20160526.deb (~27MB)

Best,

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

Re: [PD] problems with footils fluid~

[Ivica Bukvic]

In follow-up to this, it appears that 14.04 Ubuntu 64bit works just fine
with the latest flext and fluid~ whereas the same code base crashes on
16.04 64bit. Apart from kernel and other OS changes, another variable in
play: 16.04 is a newer Sandy Bridge machine whereas the 14.04 is an older
AMD APU machine.

What I discovered is that if in fluid::fluid_init method if I comment out:

//if (settings != NULL )
// delete_fluid_settings(settings);

everything seems to work fine, although this is likely resulting in a
memory leak. Could it be that the newer gcc is more sensitive to how things
are handled there?

Best,

Ico

On Sun, May 22, 2016 at 6:31 PM, Ivica Bukvic  wrote:

> All,
>
> It appears since sometime earlier this year (possibly with upgrade to
> Ubuntu 15.10 and newer), fluid~ external crashes as soon as you enable
> dac~. It worked perfectly fine before. The backtrace is fairly cryptic
> suggesting something is wrong with the libfluidsynth. Yet, other apps that
> use it work just fine (e.g. Qsynth). To make matters more complicated,
> fluid~ uses flext library, although other externals work fine with the
> current version of flext.
>
> Below is the gdb backtrace:
>
> #0  0x in ?? ()
> #1  0x7fffdab6e691 in fluid_hashtable_lookup ()
>from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
> #2  0x7fffdab6f51e in ?? ()
>from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
> #3  0x7fffdab71448 in fluid_settings_getint ()
>from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
> #4  0x7fffdab6a026 in fluid_LADSPA_run ()
>from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
> #5  0x7fffdab7d3b7 in fluid_rvoice_mixer_render ()
>from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
> #6  0x7fffdab8399d in fluid_synth_write_float ()
>from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
> #7  0x7fffdae28908 in fluid::m_signal(int, float* const*, float*
> const*) ()
>from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux
> #8  0x7fffdae29fcb in flext_dsp_multi::dspmeth(long*) ()
>from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux
> #9  0x004b3bc5 in dsp_tick () at d_ugen.c:336
> #10 0x004a3093 in sched_tick () at m_sched.c:385
> #11 0x004a34be in m_pollingscheduler () at m_sched.c:485
> #12 m_mainloop () at m_sched.c:563
>
> Is this a know issue? It wasn't a problem until I upgraded to 15.10 (from
> 14.04) and it seems 16.04 (64bit) is also problematic. Has anyone had any
> luck recently with the fluid~ external?
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] problems with footils fluid~

[Ivica Bukvic]

All,

It appears since sometime earlier this year (possibly with upgrade to
Ubuntu 15.10 and newer), fluid~ external crashes as soon as you enable
dac~. It worked perfectly fine before. The backtrace is fairly cryptic
suggesting something is wrong with the libfluidsynth. Yet, other apps that
use it work just fine (e.g. Qsynth). To make matters more complicated,
fluid~ uses flext library, although other externals work fine with the
current version of flext.

Below is the gdb backtrace:

#0  0x in ?? ()
#1  0x7fffdab6e691 in fluid_hashtable_lookup ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#2  0x7fffdab6f51e in ?? ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#3  0x7fffdab71448 in fluid_settings_getint ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#4  0x7fffdab6a026 in fluid_LADSPA_run ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#5  0x7fffdab7d3b7 in fluid_rvoice_mixer_render ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#6  0x7fffdab8399d in fluid_synth_write_float ()
   from /usr/lib/x86_64-linux-gnu/libfluidsynth.so.1
#7  0x7fffdae28908 in fluid::m_signal(int, float* const*, float*
const*) ()
   from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux
#8  0x7fffdae29fcb in flext_dsp_multi::dspmeth(long*) ()
   from /usr/lib/pd-l2ork/extra/flext/fluid~.pd_linux
#9  0x004b3bc5 in dsp_tick () at d_ugen.c:336
#10 0x004a3093 in sched_tick () at m_sched.c:385
#11 0x004a34be in m_pollingscheduler () at m_sched.c:485
#12 m_mainloop () at m_sched.c:563

Is this a know issue? It wasn't a problem until I upgraded to 15.10 (from
14.04) and it seems 16.04 (64bit) is also problematic. Has anyone had any
luck recently with the fluid~ external?
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] [clone]'s instance number

[Ivica Bukvic]

What about having an if statement that detects clone object and if so,
compensates for $2 discrepancy and assigns $1 to it instead and increments
from there? This way the discrepancy is internalized as opposed to
something user needs to deal with.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On May 11, 2016 11:50, "Miller Puckette"  wrote:

> I gave this some thought but couldn't come up with anything more natural
> than
> the "$1" idea.  It allows for changing the other arguments more easily than
> it would have been if the instance number were passed last.  Also, somehow
> it felt more natural to have the instance number first.
>
> If there's interest in the idea, I could add arrguments to change the
> behavior (such as putting $1 last instead of first)...  Offhand I doubt
> that
> would get used much though.
>
> cheers
> Miller
>
>
>
> On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
> > There's also a pitfall: additional creation arguments for the cloned
> abstraction will start with $2.
> > For example, in [clone 16 my-abstraction 1 5 9] '1' will be parsed as
> $2, '5' as $3, '9' as $4 etc.
> > No problem, if the abstraction was written for being used with [clone],
> but bad when cloning existing abstractions.
> >
> > I'm wondering if there could be a way to get the abstraction ID without
> messing up existing abstractions... Maybe have a dedicated object?
> >
> > For now, I think it's important to mention the parsing of additional
> creation arguments in the help file.
> >
> > Christof
> >
> > > Gesendet: Mittwoch, 11. Mai 2016 um 16:25 Uhr
> > > Von: "IOhannes m zmoelnig" 
> > > An: pd-list@lists.iem.at
> > > Betreff: Re: [PD] [clone]'s instance number
> > >
> > > On 2016-05-11 16:18, Liam Goodacre wrote:
> > > > Would it be possible to access [clone]'s unique instance number from
> within the patch, a bit like a creation argument? This could be used to
> achieve differentiation between the abstractions, ie. if the abstraction
> contains "tabread4~ $-1.array" and the $-1 is replaced with the instance
> number, then each instance could read a different file. Of course there are
> other ways of doing this, but it would be neat to do it with clone, and I'm
> wondering if there's a way.
> > >
> > >
> > > isn't this what $1 is already doing in clone's instances?
> > >
> > >
> > > fgasdmr
> > > 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
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd-l2ork GUI port Alpha 0

[Ivica Bukvic]

On Apr 12, 2016 13:00, "Alexandre Torres Porres"  wrote:
>
> 2016-04-12 13:05 GMT-03:00 Ivica Bukvic :
>>
>> pd-l2ork has had the -legacy startup flag for some time now that ensures
that all the patches will render according to legacy GUI positioning.
>
> just so I get it, but then pd-l2ork patches won't load accordingly, right?

Not sure what you mean. You can open patches from either but if you use
legacy positioning that will affect all the patches opened under that
instance. We may want to look into per patch setting but as of right now I
don't think that's worth the effort because users as far as I can tell tend
not to mix the two. HTH

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

Re: [PD] Pd-l2ork GUI port Alpha 0

[Ivica Bukvic]

I will let Jonathan answer the bulk of your questions pertaining to the
latest GUI port. As far as GUI objects being offset, pd-l2ork has had the
-legacy startup flag for some time now that ensures that all the patches
will render according to legacy GUI positioning.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Apr 12, 2016 12:00, "Roman Haefeli"  wrote:

> On Fri, 2016-04-08 at 14:38 +, Jonathan Wilkes via Pd-list wrote:
> > Hi list,
> > Here are some binaries to test out the alpha 0 release for the GUI
> > port of Pd-l2ork.
>
> Wow.. impressive work you've done and I think I'm not even remotely able
> to grasp what it meant to achieve this. I very much like its native look
> (I checked on Ubuntu 14.04). Also the GUI tab in the preferences dialog,
> very neat. And the canvas zoom is probably going to be _the_ killer
> feature with all the hi-res displays coming up.
>
> Some observations (from Ubuntu 14.04 i386):
>
> * For a true vanilla experience, it'd be nice if the GUI preset
>  'vanilla' would use bold fonts.
>
> * I sometimes have to click on Menus twice for the selected item to show
>   up. I couldn't figure out a reliable pattern. Affected entries:
>   'Media->Test Audio and Midi' or 'Edit -> Preferences'
>
> * I can't load many of my patches in this nw-version of Pd-l2ork. When I
>   do so, the patch canvas never appears and I get repeating messages
>   'watchdog: signaling pd..' on stderr. The process 'nw' uses 100% of a
>   core and I have to kill pd-l2ork. Some simple patches work fine and I
>   haven't figured out a pattern of what kind of patches are affected
>   which are not. However, the behaviour of a certain patch is consistent
>   (either it loads always ok or it never does so).
>   UPDATE: Not true. It just takes that much time to load the patch. The
>   one I just loaded took more than 2 minutes to load.
>
> What version of Pd-vanilla is this based on? Or is not related to
> vanilla anymore? I stopped caring about Pd-l2ork when I figured it
> contains some fixes that shifts position of iemguis around. This
> renders a lot of my patches unusable because they are not displayed in
> the GOP area anymore. I'd love if patches would work in both flavors,
> but right now it seems as a patch author you need to decide one.
>
> Is it correct that externals for Pd-l2ork are binary-incompatible with
> externals built for Pd-vanilla? I'm just interested to know, maybe this
> isn't such a huge issue, since Pd-l2ork has so many externals
> pre-compiled.
>
> Roman
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Help Patches Layout

[Ivica Bukvic]

On Mar 17, 2016 2:03 PM, "Esteban Viveros"  wrote:
>>
>>
>> If you are determined to update all the docs to reflect this change,
don't forget the PD_META which currently requires the use of 0 as the first
inlet. Updating tooltips will also require changes accommodate for this
alteration.
>
>
> I did not attack me so... Rename in there have some implication? If no, I
will start to rename...

This is where tooltips pull their documentation information when you hover
with your mouse over inlets, outlets, or the object itself. These changes
will require changes in C, GUI, and may also affect compatibility between
vanilla and pd-l2ork. My advice would be at this point not to worry about
it and focus on other aspects until we think this through a little bit.

>
>>
>> Best,
>>
>> Ico
>>
>>
>> On 3/17/2016 1:13 PM, Esteban Viveros wrote:
>>>
>>> Thanks Roman for explanations.. good trim the edges of naming things in
order to eliminate future confusion.
>>>
>>> Ivica, I'm thinking in order to provide a relatively see and understand
for help patch user. Is really necessary expose a new user to this
problematics?
>>>
>>> I'm thinking which not every pd user must be a programmer (at least
initially), and probably be an artist... (perhaps), thinking this I
understand the principal goal of the user is to make thinks work, and to
use the send a message to this object he needs do use $1  $2 $3, if he use
$0 pd will do other thing.. So name outlets in Help from 0 require one more
step for who are learning many more steps...  (please correct me if I'm
wrong with regard to the behavior pd)
>>>
>>> Finally, open and edit patch by patch I'm already doing.. Rename inlets
and outlets I can make like meditation! :P
>>>
>>> I'm question for these because I know pdL2ork have other libraries and
have change something like this have consequences. But anyway, if needed I
can modify some more patches. :) Only it will have some time.
>>>
>>> Cheers
>>>
>>>
>>> Em qui, 17 de mar de 2016 às 13:26, Ivica Ico Bukvic 
escreveu:

 Here's my $0-cents worth. This is an eternal struggle in the
world'o'comp sci. We need to wrap our heads around the fact that 0 is the
1st number in any kind of data container, whether it be value or ordinal
position. Yet, as humans we prefer 1 to be that first number, reserving 0
as the special case value. So, you could make the case either way arguing
for consistency, intuitiveness, aliens, whatever. Another consideration
within the pd* ecosystem is that it is 0-centric, meaning things tend to
start with $0 (patch instance) before they get to $1. Then again, $1 refers
to the first arg, so you could argue it may be inconsistent... etc. etc.
etc.

 On the practical side, renaming inlets would mean going through every
last help file and ensuring it has been updated accordingly, otherwise you
would be just adding to more confusion as newcomers learn that some help
files refer to the first inlet as 0 and others as 1...


 On 3/17/2016 11:49 AM, Esteban Viveros wrote:
>
> Hi,
>
> I'm with Porres in Cyclone maintenance working on revision of some
Help patches.
>
> The question is: Why count inlets and outlets from zero if Pd user
have to call inlets and outlets from $1 $2 $3... ? For help patch user
don't be more convenient enumerate inlets and outlets starting at number 1?
>
> Cheers
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

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

Re: [PD] GUI port: full triforce

[Ivica Bukvic]

Fantastic work, Jonathan!

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Mar 15, 2016 22:25, "Jonathan Wilkes via Pd-list" 
wrote:

> Hi list,
> I now have the GUI port of Pd-l2ork up and running on GNU/Linux, OSX, and
> Windows.
>
> One final dungeon of build script revisions and I'll release an alpha.
>
> -Jonathan
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Cyclone future

[Ivica Bukvic]

If anyone wants git access to pd-l2ork with the intent of continuing to
develop cyclone under the same name including bug fixes and feature
additions to existing as well as introducing new objects, please email me
off-list.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 23, 2016 4:47 PM, "Alexandre Torres Porres"  wrote:

> I'm seconding Dan on this, name ideas was something being proposed to me
> and all before Fred shared his intention to stop working on "cyclone". I
> didn't even liked the idea of forking cyclone then, the reason being that
> there was no significant change for for projects, one only being able to be
> updated...
>
>
> now, from a previous thread
>
> 2016-02-20 15:57 GMT-02:00 Matt Barber :
>
>> If a Max 4.6 compatibility library is really necessary, perhaps that
>> could be the fork with the new name.
>>
>
> I agree to Matt on this too, but with the remark that Max 4.6
> compatibility would also be present in the updates and further development
> of cyclone
>
> keeping it simple, the whole issue camos with some of us wanting to
> collaborate and work on updates of cyclone, and the current maintainer
> having issues with it, it's not that he didn't want to spend his time
> working on it, more like he was against that others would help him do that.
>
> do we really need to fork in order to update a library keeping its
> original goal?
>
> I'm ok with whatever the community think it's best. I already started
> working a lot on this and now I'm just on it, 20 new objects in the way, a
> whole revision of all help files going on, it's happening...
>
> cheers
>
> 2016-02-23 18:08 GMT-03:00 Dan Wilcox :
>
>> If neither krzysztof not Fred plan to continue development, why can’t it
>> continue under the same name? (Keeping attribution of course!) I’d argue
>> multiple libraries is more confusing to the user especially when they all
>> provide roughly the same functionality but the main one is now very out of
>> date. That, plus the fact that urging people to use [declare -lib cyclone]
>> now requires urging people to do a batch find/replace for “cyclone” when,
>> again, the functionality is the same.
>>
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com
>> robotcowboy.com
>>
>> On Feb 23, 2016, at 1:32 PM, pd-list-requ...@lists.iem.at wrote:
>>
>> i therefore ask both fred and alexandre to change the name of their
>> library, so that they cannot be confused with both the original cyclone
>> library and with each other: neither of the forks is an (or /the/)
>> "official" fork.
>> for what it is worth, git makes it easy to incorporate changes between
>> forks (using pull requests, cherry picking,...) even if the names are
>> different!
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] opensoundcontrol.org

[Ivica Bukvic]

Could be also because Matt Wright (who I believe is the OSC author) has
left CNMAT and is now at Stanford (AFAIK).

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 18, 2016 3:16 AM, "IOhannes m zmoelnig"  wrote:

> On 2016-02-18 07:27, Dan Wilcox wrote:
> > Does anyone know who runs opensoundcontrol.org <
> http://opensoundcontrol.org/>? It’s down and has been down for a few
> weeks now. Did CNMAT forget to pay the bill?
>
> last time i checked (less than half a year ago), CNMAT still ran the site.
> last time i checked was because the page was  unavailable.
> it turned out than all of CNMATs webpages were offline (think ddos).
>
> fgmkasdrt
> IOhannes
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres

[Ivica Bukvic]

On Sun, Feb 14, 2016 at 11:27 PM, Jonathan Wilkes 
wrote:

> Ivica,
> The point is that with control objects one could make an object that
> maps "n" abstraction inlets to a single object.  That single object can
> just prepend incoming messages with an index.  Same with dispatching
> objects to "n" outlets.
>
> Doing it that way allows the user to create abstractions with variable
> xlets
> without relying at all on dynamic patching.  Thus the patches end up more
> maintainable and easier to reason about.
>

Perhaps but this is not a case of multiple nlets. Rather it is a way to
sidestep multiple nlets limitation that does not map 1:1 to the other
solution as it requires prepending (or providing data for all nlets in a
form of a list).


>
> You can't do the same with signal connections.  So you'd have to sprout
> as many outlets from your object as you have inlets, in which case it's
> nearly
> the same complexity as dynamic patching with [inlet~].
>

True.


>
> -Jonathan
>
>
> On Sunday, February 14, 2016 7:26 PM, Matt Barber 
> wrote:
>
>
> I asked for something like Antoine's design back in 2007. I think it's a
> great idea, because it behaves like a signal inlet in compiled objects.
> On Feb 14, 2016 6:48 PM, "Ivica Bukvic"  wrote:
>
>
> On Sun, Feb 14, 2016 at 5:54 PM, Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at> wrote:
>
> Hi Antoine,
> We're talking about two different kinds of "dynamic" nlets.  Yours seems
> to
> set a value for the signal based on whether or not there is a connection
> to that
> inlet.  What I'm talking about is a future object that would elegantly
> handle
> the creation of a variable number of inlets(~) or outlets(~) inside an
> abstraction.
>
> I'm pressing Ivica specifically on variable signal nlets because there's
> no way
> to flexibly handle them.
>
>
> Why not? First of all, we need to agree that such an object would be
> mostly useful at instantiation time (e.g. a silly example would be an
> abstraction that mimics selector~ behavior) and in dynamic patching where
> after creation one would need to connect bunch of stuff to this object and
> ensure that inside the abstraction additional inlets actually do something.
> Second, let's assume the dynamic nlet creation object is the rightmost
> object (otherwise user is asking for potential problems if something is
> already connected to the second inlet and then suddenly first inlet grows a
> couple more inlets before the second one--even this could be potentially
> handled, with adequate changes inside the pd core, or in this case pd-l2ork
> core). Now, if new nlets are generated, they will not autoconnect to
> anything--this is user's responsibility likely through some sort of live or
> scripted patching at instantiation time which could be driven from the same
> argument. Once that is all taken into an account, the last thing is to
> consider:
>
> suspend dsp
> instantiate new object
> rebuild dsp graph (as you would with instantiation of any new signal object
> resume dsp
> redraw object and parent object on its parent canvases
>
> One lingering concern is that this would effectively make the abstraction
> dirty which could be either seen as a good thing or handled as something
> that does not trigger the dirty flag.
>
> Best,
>
> Ico
>
>
>
> -Jonathan
>
>
> On Sunday, February 14, 2016 5:34 PM, Antoine Rousseau 
> wrote:
>
>
> I've only partially followed all this discussion (not using Max myself),
> but maybe an object I wrote could help you building such abstractions :
>
> [moonlib/dinlet~] is an [inlet~] with an init float value (constant
> signal) as an argument.
> This default value is overloaded when a signal is connected to the inlet,
> but restored when the signal is disconnected. A float sent to it would
> overwrite the default constant value.
>
> Of course the init default value could be one of the abstraction's
> arguments ($xxx)...
>
> BUT :
>
> - there is a very little hack (which could be called a bugfix...) that has
> to be made to pd source (this change is written in comment in the source
> file of dinlet~). I should open a ticket for that in the sourceforge repo.
> The involved bug is mixing the different float values up when [dinlet~] is
> used together with normal [inlet]s.
>
> - I should add a missing feature in dinlet~, which would add an inlet to
> the [dinlet~] object itself, to allow changing the default value inside of
> the abstraction.
>
> If anyone think this would be helpful, I could do this (open a ticket and
> update moonlib about this

Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres

[Ivica Bukvic]

On Sun, Feb 14, 2016 at 5:54 PM, Jonathan Wilkes via Pd-list <
pd-list@lists.iem.at> wrote:

> Hi Antoine,
> We're talking about two different kinds of "dynamic" nlets.  Yours seems
> to
> set a value for the signal based on whether or not there is a connection
> to that
> inlet.  What I'm talking about is a future object that would elegantly
> handle
> the creation of a variable number of inlets(~) or outlets(~) inside an
> abstraction.
>
> I'm pressing Ivica specifically on variable signal nlets because there's
> no way
> to flexibly handle them.
>

Why not? First of all, we need to agree that such an object would be mostly
useful at instantiation time (e.g. a silly example would be an abstraction
that mimics selector~ behavior) and in dynamic patching where after
creation one would need to connect bunch of stuff to this object and ensure
that inside the abstraction additional inlets actually do something.
Second, let's assume the dynamic nlet creation object is the rightmost
object (otherwise user is asking for potential problems if something is
already connected to the second inlet and then suddenly first inlet grows a
couple more inlets before the second one--even this could be potentially
handled, with adequate changes inside the pd core, or in this case pd-l2ork
core). Now, if new nlets are generated, they will not autoconnect to
anything--this is user's responsibility likely through some sort of live or
scripted patching at instantiation time which could be driven from the same
argument. Once that is all taken into an account, the last thing is to
consider:

suspend dsp
instantiate new object
rebuild dsp graph (as you would with instantiation of any new signal object
resume dsp
redraw object and parent object on its parent canvases

One lingering concern is that this would effectively make the abstraction
dirty which could be either seen as a good thing or handled as something
that does not trigger the dirty flag.

Best,

Ico


>
> -Jonathan
>
>
> On Sunday, February 14, 2016 5:34 PM, Antoine Rousseau 
> wrote:
>
>
> I've only partially followed all this discussion (not using Max myself),
> but maybe an object I wrote could help you building such abstractions :
>
> [moonlib/dinlet~] is an [inlet~] with an init float value (constant
> signal) as an argument.
> This default value is overloaded when a signal is connected to the inlet,
> but restored when the signal is disconnected. A float sent to it would
> overwrite the default constant value.
>
> Of course the init default value could be one of the abstraction's
> arguments ($xxx)...
>
> BUT :
>
> - there is a very little hack (which could be called a bugfix...) that has
> to be made to pd source (this change is written in comment in the source
> file of dinlet~). I should open a ticket for that in the sourceforge repo.
> The involved bug is mixing the different float values up when [dinlet~] is
> used together with normal [inlet]s.
>
> - I should add a missing feature in dinlet~, which would add an inlet to
> the [dinlet~] object itself, to allow changing the default value inside of
> the abstraction.
>
> If anyone think this would be helpful, I could do this (open a ticket and
> update moonlib about this missing inlet).
>
>
>
> 2016-02-14 20:29 GMT+01:00 Jonathan Wilkes via Pd-list <
> pd-list@lists.iem.at>:
>
> > Why not simply have an inlet that can handle both inside an abstraction
> and route signal one way and number the other and then sprinkle that with
> dynamic nlet creation and you're done? Then you can simply abstract most
> cases.
>
> I read (and like) your spec on dynamic nlet creation, but I have a problem
> with section 2.1 Signals:
>
> "To handle the dynamic creation of signal inlets and their routing within
> the abstraction, the implementation must"
>
> It looks like the rest of the section is missing. :)
>
> -Jonathan
>
>
>
>
> On Sunday, February 14, 2016 1:51 PM, Matt Barber 
> wrote:
>
>
> ​I tried coding that once, but it seemed like it needed some big change in
> architecture. Technically it's only the main signal that accepts both
> messages and signals in this way, where you would want to route the
> message. Floats should almost always be promoted to signals.​
>
> On Sun, Feb 14, 2016 at 1:18 PM, Ivica Ico Bukvic  wrote:
>
> Why not simply have an inlet that can handle both inside an abstraction
> and route signal one way and number the other and then sprinkle that with
> dynamic nlet creation and you're done? Then you can simply abstract most
> cases.
>
>
> On 2/14/2016 11:36 AM, Matt Barber wrote:
>
> [gt~] is a great example of something that could work a

Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres

[Ivica Bukvic]

Well, if it does not break backwards compatibility of nlets, I am all for
including it in pd-l2ork...

On Sun, Feb 14, 2016 at 1:38 PM, Matt Barber  wrote:

> ​I tried coding that once, but it seemed like it needed some big change in
> architecture. Technically it's only the main signal that accepts both
> messages and signals in this way, where you would want to route the
> message. Floats should almost always be promoted to signals.​
>
> On Sun, Feb 14, 2016 at 1:18 PM, Ivica Ico Bukvic  wrote:
>
>> Why not simply have an inlet that can handle both inside an abstraction
>> and route signal one way and number the other and then sprinkle that with
>> dynamic nlet creation and you're done? Then you can simply abstract most
>> cases.
>>
>>
>> On 2/14/2016 11:36 AM, Matt Barber wrote:
>>
>> [gt~] is a great example of something that could work as an abstraction,
>> except for the pesky right inlet which should take a signal if there's no
>> creation argument, but float otherwise.
>>
>> On Sun, Feb 14, 2016 at 10:50 AM, Ivica Bukvic  wrote:
>>
>>> What I am also trying to do eventually in pd-l2ork is weed out redundant
>>> objects and only keep the ones that do the said task the best while still
>>> supporting other objects' idiosyncrasies (if any). There is absolutely no
>>> reason to have multiple objects of the same kind. Ultimately, one could
>>> keep all the externals in the same folder and completely do away with all
>>> the declares, imports, and other things that make learning pd unnecessarily
>>> harder.
>>>
>>> --
>>> Ivica Ico Bukvic, D.M.A.
>>> Associate Professor
>>> Computer Music
>>> ICAT Senior Fellow
>>> Director -- DISIS, L2Ork
>>> Virginia Tech
>>> School of Performing Arts – 0141
>>> Blacksburg, VA 24061
>>> (540) 231-6139
>>> i...@vt.edu
>>> www.performingarts.vt.edu
>>> disis.icat.vt.edu
>>> l2ork.icat.vt.edu
>>> ico.bukvic.net
>>> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  wrote:
>>>
>>>> Hi Alexandre,
>>>>
>>>> guess some of it is in:
>>>>> http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
>>>>>
>>>>
>>>> This list is also becoming a list of what has been done.
>>>>
>>>>>
>>>>> As with _nettles_
>>>>>
>>>>> "try to resurrect as independent object library"
>>>>>
>>>>> Anyway, tell me if this gets includes on this file.
>>>>>
>>>>
>>>> Yes, the nettles-objects are part of the latest cyclone versions. They
>>>> are part of the nettles library, which can be loaded with [declare]. Not
>>>> all operating systems like the '<' and '>' in the object names and there is
>>>> overlap with other library objects, so only loading them when needed is
>>>> cleaner.
>>>>
>>>>>
>>>>> cheers
>>>>>
>>>>> ps. count me in for help with the help files
>>>>>
>>>>
>>>> Great!
>>>>
>>>> Greetings,
>>>>
>>>> Fred Jan
>>>>
>>>>
>>>>> 2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres >>>> <mailto:por...@gmail.com>>:
>>>>>
>>>>> Howdy, it's a known fact brazilians will start the year only after
>>>>> carnival, so here I am.
>>>>>
>>>>> I'd like to share my list of things to do with existing Cyclone
>>>>> Objetcs. Obviously there might be other issues with other objects
>>>>> that would make them up to date with the current version of Max
>>>>> (Max
>>>>> 7). Nonetheless, this is what I find relevant, and I've been really
>>>>> checking it through.
>>>>>
>>>>> It's only about 11 objects, some has already been discussed here
>>>>> and
>>>>> might have been fixed or in the process to be taken care of,
>>>>> forgive
>>>>> me if so.
>>>>>
>>>>> I have it attached and also as a link to a google doc
>>>>>
>>>>>
>>>>> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>>>>>
>>>>> Next, I will get together a list of new objects I think should be
>>>>> included, many of which I've already made as abstractions (kind of
>>>>> to show how it works like I did with [teeth~], cause I really think
>>>>> they should all be done as externals).
>>>>>
>>>>> Cheers
>>>>>
>>>>>
>>>>>
>>>> ___
>>>> Pd-list@lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management ->
>>>> <http://lists.puredata.info/listinfo/pd-list>
>>>> http://lists.puredata.info/listinfo/pd-list
>>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> <http://lists.puredata.info/listinfo/pd-list>
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Nettles. Was: Cyclone: List of Issues with existing objects by Alexandre Porres

[Ivica Bukvic]

What I am also trying to do eventually in pd-l2ork is weed out redundant
objects and only keep the ones that do the said task the best while still
supporting other objects' idiosyncrasies (if any). There is absolutely no
reason to have multiple objects of the same kind. Ultimately, one could
keep all the externals in the same folder and completely do away with all
the declares, imports, and other things that make learning pd unnecessarily
harder.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"  wrote:

> Hi Alexandre,
>
> guess some of it is in:
>> http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
>>
>
> This list is also becoming a list of what has been done.
>
>>
>> As with _nettles_
>>
>> "try to resurrect as independent object library"
>>
>> Anyway, tell me if this gets includes on this file.
>>
>
> Yes, the nettles-objects are part of the latest cyclone versions. They are
> part of the nettles library, which can be loaded with [declare]. Not all
> operating systems like the '<' and '>' in the object names and there is
> overlap with other library objects, so only loading them when needed is
> cleaner.
>
>>
>> cheers
>>
>> ps. count me in for help with the help files
>>
>
> Great!
>
> Greetings,
>
> Fred Jan
>
>
>> 2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres > >:
>>
>> Howdy, it's a known fact brazilians will start the year only after
>> carnival, so here I am.
>>
>> I'd like to share my list of things to do with existing Cyclone
>> Objetcs. Obviously there might be other issues with other objects
>> that would make them up to date with the current version of Max (Max
>> 7). Nonetheless, this is what I find relevant, and I've been really
>> checking it through.
>>
>> It's only about 11 objects, some has already been discussed here and
>> might have been fixed or in the process to be taken care of, forgive
>> me if so.
>>
>> I have it attached and also as a link to a google doc
>>
>>
>> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>>
>> Next, I will get together a list of new objects I think should be
>> included, many of which I've already made as abstractions (kind of
>> to show how it works like I did with [teeth~], cause I really think
>> they should all be done as externals).
>>
>> Cheers
>>
>>
>>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Cyclone: List of Issues with existing objects by Alexandre Porres

[Ivica Bukvic]

This is something I did not know about Max. I presume that is only with
signal objects as I don't recall seeing that with non-signal ones? Perhaps
this would be an opportunity to revisit nlet code to make it more
versatile? I have on pd-l2ork's TODO to explore implementing nlets that can
split signal and non signal, as well as refuse to connect things that
shouldn't be connected, which works only in some cases. Perhaps this calls
to also report when something is connected into the nlet?

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 13, 2016 2:00 PM, "Alexandre Torres Porres"  wrote:

> As Ivica mentioned, abstractions are preferable from an educational point
>> of view. And they are easier to maintain... So I see no problem adding them
>> just like [teeth~]. If performance gets an issue, it is always possible to
>> code that object, or its critical part, in c.
>>
>
> The problem with teeth~ now is that it has no arguments. Ok, that's easy
> to fix, but there's a problem managing arguments with abstractions, and
> this is what I was trying to explain in response to Ivica's email.
>
> For example, in [comb~], if you send a signal to an inlet, it overwrites
> the argument value, but if you disconnect that signal connection it will
> revert to the argument's value. That's how it works in Max too and I don't
> know any other way to achieve this other than with an external.
>
> Please find attached an example with comb~ that illustrates this, when you
> disconnect the signal connection (value of 0) it'll restore the argument
> value (0.99).
>
> Anyway, this is a common behaviour for such objetcs, so even if it's cool
> and easy to make an abstraction, ot's just best for the design if you code
> an external.
>
> Another issue I could point with an abstraction in Pd for [teeth~] is that
> the delay objects are kinda buggy in Pd, where you can't really go up to
> the specified delay lenght. I've already reported this by the way. So, a
> more accurate delay network could be achieved with an external.
>
> Moreover, it should be really easy to make a teeth~ external from the code
> in  comb~
>
> cheers
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Cyclone To Do: list of new objects; Any help?

[Ivica Bukvic]

I would love to see these implemented, as well, in vanilla cyclone library,
with one caveat: wherever possible, I would suggest using an abstraction.
Doing so promotes learning and exposes brilliant efficiency of the
pure-data core. For instance, one thing that pd-l2ork already does is it
provides [prepend] as an abstraction that also annoyingly spits out a
warning in the console that the object is deprecated in favor of [list
prepend]. While I am sure not everyone agrees with the nagging aspect of
the object, this way, users are nudged in the right direction, have an
opportunity to dissect the abstraction, while also retaining
cross-compatibility. Sure, this may be less efficient than a native object,
but likely not by much. Just a thought...

On Thu, Feb 11, 2016 at 9:43 PM, Alexandre Torres Porres 
wrote:

> Howdy, here's a list of relevant new objects to include as externals in
> Pd. some of them are here because they are just easy and because I was able
> to do as abstractions or even make an external code draft. Some aren't that
> simple but I've made into abstractions as well.
>
> Anyway, this is what I find important and suggest to have as externals in
> Pd as we're still missing useful features from them
>
> see attachment and the google docs here
>
>
> https://docs.google.com/document/d/1CBRd1sOf4ebJmdqQfUtcCJzS2ZRhvMgoyLz8pNPD6mc/edit?usp=sharing
>
> Since I can't code, and since I realize that maintaining the existing
> library is enough work for now for Fred Jan, we'd need help from
> enthusiastic coders out there, so I'm trying to recrute friends for the
> task.
>
> cheers
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] freeverb~ problem

[Ivica Bukvic]

Do denormal optimizations also handle NaNs?

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 8, 2016 1:59 PM, "Kjetil Matheussen" 
wrote:

> Carl Hetherington has a good write up on denormals:
> http://carlh.net/plugins/denormals.php
>
> This is the most interesting point:
>
>"The P3 always has problems with denormals no matter what GCC flags or
> CPU modes are used.".
>
> So unless you want your program to function on a P3, you can safely compile
> your denormal-creating program with sse math and turn on DAZ and FTZ.
> You won't get any problems with denormals then.
>
>
>
>
>
>
>
> On Mon, Feb 8, 2016 at 4:13 PM, Ivica Ico Bukvic  wrote:
>
>> I thought this, too. I seem to (mis)remember somewhere that -O2
>> optimization at compile-time would help with this, which is what pd-l2ork's
>> freeverb~ uses and still exhibits previously reported behavior. That said,
>> I wonder if denormals would also solve potential NaNs. At any rate, I've
>> updated freeverb~ to explicitly use denormal function's return value in
>> pd-l2ork and will run some tests and let you know. If you'd like to test it
>> out, download the latest deb dated 20160208 (64bit build only for the time
>> being).
>>
>> Best,
>>
>> Ico
>>
>>
>> On 2/8/2016 4:44 AM, Kjetil Matheussen wrote:
>>
>> Regarding denormals, if that's the problem, shouldn't it be good enough
>> to compile with -fpmath=sse -msse2 and run the following code one time in
>> the dsp thread?
>>
>> #ifdef __SSE__
>> #ifdef __SSE2__
>> #define AVOIDDENORMALS _mm_setcsr(_mm_getcsr() | 0x8040)
>> #else
>> #define AVOIDDENORMALS _mm_setcsr(_mm_getcsr() | 0x8000)
>> #endif
>> #else
>> #   error "must compile with -fmpath=sse"
>> #endif
>>
>>
>>
>>
>> On Mon, Feb 8, 2016 at 10:28 AM, Kjetil Matheussen <
>> k.s.matheus...@gmail.com> wrote:
>>
>>> You could use the faust version of freeverb and compile it for pd. It's
>>> probably less likely to have bugs.
>>> For instance by pasting
>>> http://sourceforge.net/p/faudiostream/code/ci/master/tree/examples/freeverb.dsp?format=raw
>>> into http://faust.grame.fr/onlinecompiler/
>>>
>>>
>>> On Sun, Feb 7, 2016 at 4:08 AM, Ivica Bukvic < i...@vt.edu>
>>> wrote:
>>>
>>>> Thank you, Katja. Is there a newer version than this out there?
>>>>
>>>> Best,
>>>>
>>>> --
>>>> Ivica Ico Bukvic, D.M.A.
>>>> Associate Professor
>>>> Computer Music
>>>> ICAT Senior Fellow
>>>> Director -- DISIS, L2Ork
>>>> Virginia Tech
>>>> School of Performing Arts – 0141
>>>> Blacksburg, VA 24061
>>>> (540) 231-6139 <%28540%29%20231-6139>
>>>> i...@vt.edu
>>>> www.performingarts.vt.edu
>>>> disis.icat.vt.edu
>>>> l2ork.icat.vt.edu
>>>> ico.bukvic.net
>>>> On Feb 6, 2016 10:25 AM, "katja"  wrote:
>>>>
>>>>> If the freeverb~ version you use looks like the one in
>>>>>
>>>>> http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/freeverb~/freeverb~.c
>>>>> ,
>>>>> there's a function 'fix_denorm_nan_float() defined starting at line
>>>>> 154. The function is called later (in line 225 and others) but the
>>>>> return value is never stored. Therefore freeverb~ doesn't flush
>>>>> denormals.
>>>>>
>>>>> On Sat, Feb 6, 2016 at 3:34 PM, Ivica Bukvic  wrote:
>>>>> > Thank you all. Looks like I've got some troubleshooting to do and
>>>>> will
>>>>> > report what I find.
>>>>> >
>>>>> > Best,
>>>>> >
>>>>> > --
>>>>> > Ivica Ico Bukvic, D.M.A.
>>>>> > Associate Professor
>>>>> > Computer Music
>>>>> > ICAT Senior Fellow
>>>>> > Director -- DISIS, L2Ork
>>>>> > Virginia Tech
>>>>> > School of Performing Arts – 0141
>>>>> > Blacksburg, VA 24061
>>>&

Re: [PD] freeverb~ problem

[Ivica Bukvic]

Thank you, Katja. Is there a newer version than this out there?

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 6, 2016 10:25 AM, "katja"  wrote:

> If the freeverb~ version you use looks like the one in
>
> http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/freeverb~/freeverb~.c
> ,
> there's a function 'fix_denorm_nan_float() defined starting at line
> 154. The function is called later (in line 225 and others) but the
> return value is never stored. Therefore freeverb~ doesn't flush
> denormals.
>
> On Sat, Feb 6, 2016 at 3:34 PM, Ivica Bukvic  wrote:
> > Thank you all. Looks like I've got some troubleshooting to do and will
> > report what I find.
> >
> > Best,
> >
> > --
> > Ivica Ico Bukvic, D.M.A.
> > Associate Professor
> > Computer Music
> > ICAT Senior Fellow
> > Director -- DISIS, L2Ork
> > Virginia Tech
> > School of Performing Arts – 0141
> > Blacksburg, VA 24061
> > (540) 231-6139
> > i...@vt.edu
> > www.performingarts.vt.edu
> > disis.icat.vt.edu
> > l2ork.icat.vt.edu
> > ico.bukvic.net
> >
> > On Feb 6, 2016 9:20 AM, "IOhannes m zmölnig"  wrote:
> >>
> >> On 02/06/2016 10:29 AM, katja wrote:
> >> > Possibly an inf or nan recirculating in the delay lines? It seems that
> >> > freeverb~ calls function fix_denorm_nan_float(float v) but doesn't use
> >> > the return value.
> >>
> >> you *might* be able to confirm this by sending the output for
> >> [freeverb~] to [print~] (the silent samples would be NaN or Inf rather
> >> than 0 (or some other constant value))
> >>
> >> gamds
> >> IOhannes
> >>
> >>
> >>
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] freeverb~ problem

[Ivica Bukvic]

Thank you all. Looks like I've got some troubleshooting to do and will
report what I find.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 6, 2016 9:20 AM, "IOhannes m zmölnig"  wrote:

> On 02/06/2016 10:29 AM, katja wrote:
> > Possibly an inf or nan recirculating in the delay lines? It seems that
> > freeverb~ calls function fix_denorm_nan_float(float v) but doesn't use
> > the return value.
>
> you *might* be able to confirm this by sending the output for
> [freeverb~] to [print~] (the silent samples would be NaN or Inf rather
> than 0 (or some other constant value))
>
> gamds
> IOhannes
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fftease 3.0 compatibility with Linux. Was Re: fftease compatibility with Pd-0.46-7

[Ivica Bukvic]

Regarding gui slowness, this is because in PD-l2ork the entire canvas is
drawn using SVG shapes and hence the slowdown. As we migrate on to our new
renderer thanks to Jonathan's hard work, things should get exponentially
faster.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Jan 29, 2016 5:26 PM, "Ivica Bukvic"  wrote:

> Yes, RPi is not very powerful. You can always try running it without the
> GUI but I suspect that is simply what Raspberry Pi can do regardless of
> whether there is a gui or not. This is definitely the case with the first
> generation Raspberry Pi (both A and B). I haven't tried other. I am told
> they are considerably more powerful. There have been quite a few changes
> since this version was published but I simply haven't bothered building
> Raspberry Pi version. Building it should be a simple one step process and
> you can find information how to do so on the pd-l2ork website using the
> built-in script. It will however take practically a day to compile with all
> the externals. HTH
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
> On Jan 29, 2016 4:51 PM, "Samuel Burt" 
> wrote:
>
>> Ivica,
>>
>> I downloaded pd-l2ork-arm6l-20151102. Is this the latest?
>>
>> First off, "WhAaA- curvy patch cords!" The esthetics of l2ork are great.
>> I hadn't gotten around to checking it out, yet. The windows are a bit slow
>> to load, but I guess it is a compromise based on what system you are using.
>> (I'm using pd-l2ork through ssh -X from my pi2.)
>>
>> After one segmentation fault, I closed it and reopened it and tried just
>> the pvoc~ help file. After that worked, I added it into my patch. The good
>> news is it doesn't crash, now. However, the audio is stuttering a lot. So,
>> I changed the processing delay from 50ms to 100 and the clicks slowed down.
>> I have it at 200ms and it clicks about four times per second. Deleting some
>> of two out of three of the pvoc~s helps, too, but maybe [pvoc~] is too much
>> for the poor little pi.
>>
>> Even the [pvoc~] help file clicks about 7 times per second.. At least I'm
>> at a point where the object loads. I'll work at optimizing
>> efficiency/quality with the analysis window size.
>>
>> Thanks for your help.
>>
>> Sam
>>
>>
>>
>>
>> On Fri, Jan 29, 2016 at 3:30 PM Ivica Bukvic  wrote:
>>
>>> This is likely due to binary incompatibility. Please try with pd-l2ork.
>>>
>>> --
>>> Ivica Ico Bukvic, D.M.A.
>>> Associate Professor
>>> Computer Music
>>> ICAT Senior Fellow
>>> Director -- DISIS, L2Ork
>>> Virginia Tech
>>> School of Performing Arts – 0141
>>> Blacksburg, VA 24061
>>> (540) 231-6139
>>> i...@vt.edu
>>> www.performingarts.vt.edu
>>> disis.icat.vt.edu
>>> l2ork.icat.vt.edu
>>> ico.bukvic.net
>>> On Jan 29, 2016 2:56 PM, "Samuel Burt" 
>>> wrote:
>>>
>>>> Ivica,
>>>>
>>>> I'm trying it out now. I had previously tried installing pd-fftease
>>>> 2.5.2 through deken. I grabbed the lyon/ folder out of Pd-l2ork and dropped
>>>> it into ~/pd-externals. Pd was using the deken version (2.5.2), instead.
>>>> So, I removed fftease from /usr/local/lib/pd-externals and copied the lyon/
>>>> folder there. I then created [pvoc~], but when I turn on audio with a
>>>> [pvoc~] object, Pd crashes with a segmentation fault. [granola~] (the
>>>> granular pitch-shifter) works so I am assuming some of the other fftease
>>>> objects work, but [pvoc~] gave me a hard crash every time.
>>>>
>>>> I'll keep hacking away at it. If anyone else discovers a solution, let
>>>> me know. I could also reformat the patch to use the 2.5.2 [pvoc~] although
>>>> then I can't program the patch on my Mac and then transfer it straight. I'd
>>>> have to heavily modify it every time.
>>>>
>>>> Thanks for the recommendation to use pd-l2ork's libraries.

Re: [PD] fftease 3.0 compatibility with Linux. Was Re: fftease compatibility with Pd-0.46-7

[Ivica Bukvic]

Yes, RPi is not very powerful. You can always try running it without the
GUI but I suspect that is simply what Raspberry Pi can do regardless of
whether there is a gui or not. This is definitely the case with the first
generation Raspberry Pi (both A and B). I haven't tried other. I am told
they are considerably more powerful. There have been quite a few changes
since this version was published but I simply haven't bothered building
Raspberry Pi version. Building it should be a simple one step process and
you can find information how to do so on the pd-l2ork website using the
built-in script. It will however take practically a day to compile with all
the externals. HTH

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Jan 29, 2016 4:51 PM, "Samuel Burt" 
wrote:

> Ivica,
>
> I downloaded pd-l2ork-arm6l-20151102. Is this the latest?
>
> First off, "WhAaA- curvy patch cords!" The esthetics of l2ork are great. I
> hadn't gotten around to checking it out, yet. The windows are a bit slow to
> load, but I guess it is a compromise based on what system you are using.
> (I'm using pd-l2ork through ssh -X from my pi2.)
>
> After one segmentation fault, I closed it and reopened it and tried just
> the pvoc~ help file. After that worked, I added it into my patch. The good
> news is it doesn't crash, now. However, the audio is stuttering a lot. So,
> I changed the processing delay from 50ms to 100 and the clicks slowed down.
> I have it at 200ms and it clicks about four times per second. Deleting some
> of two out of three of the pvoc~s helps, too, but maybe [pvoc~] is too much
> for the poor little pi.
>
> Even the [pvoc~] help file clicks about 7 times per second.. At least I'm
> at a point where the object loads. I'll work at optimizing
> efficiency/quality with the analysis window size.
>
> Thanks for your help.
>
> Sam
>
>
>
>
> On Fri, Jan 29, 2016 at 3:30 PM Ivica Bukvic  wrote:
>
>> This is likely due to binary incompatibility. Please try with pd-l2ork.
>>
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Associate Professor
>> Computer Music
>> ICAT Senior Fellow
>> Director -- DISIS, L2Ork
>> Virginia Tech
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> i...@vt.edu
>> www.performingarts.vt.edu
>> disis.icat.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>> On Jan 29, 2016 2:56 PM, "Samuel Burt" 
>> wrote:
>>
>>> Ivica,
>>>
>>> I'm trying it out now. I had previously tried installing pd-fftease
>>> 2.5.2 through deken. I grabbed the lyon/ folder out of Pd-l2ork and dropped
>>> it into ~/pd-externals. Pd was using the deken version (2.5.2), instead.
>>> So, I removed fftease from /usr/local/lib/pd-externals and copied the lyon/
>>> folder there. I then created [pvoc~], but when I turn on audio with a
>>> [pvoc~] object, Pd crashes with a segmentation fault. [granola~] (the
>>> granular pitch-shifter) works so I am assuming some of the other fftease
>>> objects work, but [pvoc~] gave me a hard crash every time.
>>>
>>> I'll keep hacking away at it. If anyone else discovers a solution, let
>>> me know. I could also reformat the patch to use the 2.5.2 [pvoc~] although
>>> then I can't program the patch on my Mac and then transfer it straight. I'd
>>> have to heavily modify it every time.
>>>
>>> Thanks for the recommendation to use pd-l2ork's libraries.
>>>
>>> Sam
>>>
>>>
>>>
>>> On Wed, Jan 27, 2016 at 6:16 PM Ivica Bukvic  wrote:
>>>
>>>> Pd-l2ork is not binary compatible with vanilla, although non-gui
>>>> objects compiled for pd-l2ork will likely work ok.
>>>>
>>>> --
>>>> Ivica Ico Bukvic, D.M.A.
>>>> Associate Professor
>>>> Computer Music
>>>> ICAT Senior Fellow
>>>> Director -- DISIS, L2Ork
>>>> Virginia Tech
>>>> School of Performing Arts – 0141
>>>> Blacksburg, VA 24061
>>>> (540) 231-6139
>>>> i...@vt.edu
>>>> www.performingarts.vt.edu
>>>> disis.icat.vt.edu
>>>> l2ork.icat.vt.edu
>>>> ico.bukvic.net
>>>> On Jan 27, 2016 5:42 PM, "Samuel Burt" 
>>>> wrote:
>>>>
>>>>> Than

Re: [PD] fftease 3.0 compatibility with Linux. Was Re: fftease compatibility with Pd-0.46-7

[Ivica Bukvic]

This is likely due to binary incompatibility. Please try with pd-l2ork.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Jan 29, 2016 2:56 PM, "Samuel Burt" 
wrote:

> Ivica,
>
> I'm trying it out now. I had previously tried installing pd-fftease 2.5.2
> through deken. I grabbed the lyon/ folder out of Pd-l2ork and dropped it
> into ~/pd-externals. Pd was using the deken version (2.5.2), instead. So, I
> removed fftease from /usr/local/lib/pd-externals and copied the lyon/
> folder there. I then created [pvoc~], but when I turn on audio with a
> [pvoc~] object, Pd crashes with a segmentation fault. [granola~] (the
> granular pitch-shifter) works so I am assuming some of the other fftease
> objects work, but [pvoc~] gave me a hard crash every time.
>
> I'll keep hacking away at it. If anyone else discovers a solution, let me
> know. I could also reformat the patch to use the 2.5.2 [pvoc~] although
> then I can't program the patch on my Mac and then transfer it straight. I'd
> have to heavily modify it every time.
>
> Thanks for the recommendation to use pd-l2ork's libraries.
>
> Sam
>
>
>
> On Wed, Jan 27, 2016 at 6:16 PM Ivica Bukvic  wrote:
>
>> Pd-l2ork is not binary compatible with vanilla, although non-gui objects
>> compiled for pd-l2ork will likely work ok.
>>
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Associate Professor
>> Computer Music
>> ICAT Senior Fellow
>> Director -- DISIS, L2Ork
>> Virginia Tech
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> i...@vt.edu
>> www.performingarts.vt.edu
>> disis.icat.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>> On Jan 27, 2016 5:42 PM, "Samuel Burt" 
>> wrote:
>>
>>> Thanks, Ivica.
>>>
>>> I assume I can just yank all the precompiled plug-ins out of the
>>> extra/lyon/ folder. There shouldn't be any problem with that as long as I
>>> point my path to the right place?
>>>
>>> Sam
>>>
>>>
>>>
>>> On Wed, Jan 27, 2016 at 5:29 PM Ivica Bukvic  wrote:
>>>
>>>> Pd-l2ork for RPi comes prepackaged with it.
>>>>
>>>> --
>>>> Ivica Ico Bukvic, D.M.A.
>>>> Associate Professor
>>>> Computer Music
>>>> ICAT Senior Fellow
>>>> Director -- DISIS, L2Ork
>>>> Virginia Tech
>>>> School of Performing Arts – 0141
>>>> Blacksburg, VA 24061
>>>> (540) 231-6139
>>>> i...@vt.edu
>>>> www.performingarts.vt.edu
>>>> disis.icat.vt.edu
>>>> l2ork.icat.vt.edu
>>>> ico.bukvic.net
>>>> On Jan 27, 2016 5:20 PM, "Samuel Burt" 
>>>> wrote:
>>>>
>>>>> Eric,
>>>>>
>>>>> I've been so excited by the results I got after fine tuning my patch
>>>>> with [pvoc~]. [pvoc~] runs so efficiently. I never quite got [mindwarp~]
>>>>> functioning without major audio problems that I didn't have with a 
>>>>> previous
>>>>> version, though. It wasn't a big deal, because the audio routine I've
>>>>> created sounds find without it.
>>>>>
>>>>> Now, that I've got fftease 3.0 running smoothly, I discovered I can't
>>>>> run it on my Raspberry Pi. Would it be possible for me to compile it on
>>>>> Linux? or is 3.0 tuned just for the Mac, these days? Do I need to redo my
>>>>> code to use fftease 2.5?
>>>>>
>>>>> Thanks for the help.
>>>>>
>>>>> On Tue, Jan 26, 2016 at 1:03 PM Samuel Burt <
>>>>> composer.samuel.b...@gmail.com> wrote:
>>>>>
>>>>>> It's working well, now. I think there were also some compatibility
>>>>>> issues with the way the objects used to work and the way they work now. I
>>>>>> was also getting crashes, but limited the warp factor input to mindwarp~ 
>>>>>> to
>>>>>> be 1/16 to 16. I must have been sending really bad numbers.
>>>>>>
>>>>>> I didn't make clean at the end and I should check my path to make
>>>>>> sure both folders are included. Other libraries I've noticed use only one
>>>>>> folder. Any particular reason to keep them separate?
>>>>>>
>>>>>> Sam
>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>> ___
>>>>> Pd-list@lists.iem.at mailing list
>>>>> UNSUBSCRIBE and account-management ->
>>>>> http://lists.puredata.info/listinfo/pd-list
>>>>>
>>>>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Fwd: Re: fftease 3.0 compatibility with Linux. Was Re: fftease compatibility with Pd-0.46-7

[Ivica Bukvic]

Forgot to copy the list

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
-- Forwarded message --
From: "Ivica Bukvic" 
Date: Jan 27, 2016 6:16 PM
Subject: Re: [PD] fftease 3.0 compatibility with Linux. Was Re: fftease
compatibility with Pd-0.46-7
To: "Samuel Burt" 
Cc:

Pd-l2ork is not binary compatible with vanilla, although non-gui objects
compiled for pd-l2ork will likely work ok.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Jan 27, 2016 5:42 PM, "Samuel Burt" 
wrote:

> Thanks, Ivica.
>
> I assume I can just yank all the precompiled plug-ins out of the
> extra/lyon/ folder. There shouldn't be any problem with that as long as I
> point my path to the right place?
>
> Sam
>
>
>
> On Wed, Jan 27, 2016 at 5:29 PM Ivica Bukvic  wrote:
>
>> Pd-l2ork for RPi comes prepackaged with it.
>>
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Associate Professor
>> Computer Music
>> ICAT Senior Fellow
>> Director -- DISIS, L2Ork
>> Virginia Tech
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> i...@vt.edu
>> www.performingarts.vt.edu
>> disis.icat.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>> On Jan 27, 2016 5:20 PM, "Samuel Burt" 
>> wrote:
>>
>>> Eric,
>>>
>>> I've been so excited by the results I got after fine tuning my patch
>>> with [pvoc~]. [pvoc~] runs so efficiently. I never quite got [mindwarp~]
>>> functioning without major audio problems that I didn't have with a previous
>>> version, though. It wasn't a big deal, because the audio routine I've
>>> created sounds find without it.
>>>
>>> Now, that I've got fftease 3.0 running smoothly, I discovered I can't
>>> run it on my Raspberry Pi. Would it be possible for me to compile it on
>>> Linux? or is 3.0 tuned just for the Mac, these days? Do I need to redo my
>>> code to use fftease 2.5?
>>>
>>> Thanks for the help.
>>>
>>> On Tue, Jan 26, 2016 at 1:03 PM Samuel Burt <
>>> composer.samuel.b...@gmail.com> wrote:
>>>
>>>> It's working well, now. I think there were also some compatibility
>>>> issues with the way the objects used to work and the way they work now. I
>>>> was also getting crashes, but limited the warp factor input to mindwarp~ to
>>>> be 1/16 to 16. I must have been sending really bad numbers.
>>>>
>>>> I didn't make clean at the end and I should check my path to make sure
>>>> both folders are included. Other libraries I've noticed use only one
>>>> folder. Any particular reason to keep them separate?
>>>>
>>>> Sam
>>>>
>>>>
>>>>>>
>>>>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] fftease 3.0 compatibility with Linux. Was Re: fftease compatibility with Pd-0.46-7

[Ivica Bukvic]

Pd-l2ork for RPi comes prepackaged with it.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Jan 27, 2016 5:20 PM, "Samuel Burt" 
wrote:

> Eric,
>
> I've been so excited by the results I got after fine tuning my patch with
> [pvoc~]. [pvoc~] runs so efficiently. I never quite got [mindwarp~]
> functioning without major audio problems that I didn't have with a previous
> version, though. It wasn't a big deal, because the audio routine I've
> created sounds find without it.
>
> Now, that I've got fftease 3.0 running smoothly, I discovered I can't run
> it on my Raspberry Pi. Would it be possible for me to compile it on Linux?
> or is 3.0 tuned just for the Mac, these days? Do I need to redo my code to
> use fftease 2.5?
>
> Thanks for the help.
>
> On Tue, Jan 26, 2016 at 1:03 PM Samuel Burt <
> composer.samuel.b...@gmail.com> wrote:
>
>> It's working well, now. I think there were also some compatibility issues
>> with the way the objects used to work and the way they work now. I was also
>> getting crashes, but limited the warp factor input to mindwarp~ to be 1/16
>> to 16. I must have been sending really bad numbers.
>>
>> I didn't make clean at the end and I should check my path to make sure
>> both folders are included. Other libraries I've noticed use only one
>> folder. Any particular reason to keep them separate?
>>
>> Sam
>>
>>


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

Re: [PD] animation api

[Ivica Bukvic]

Create a metronome with less than 2 milliseconds clock and connect it to a
bunch of toggles, turn it on, and enjoy interacting with a barely
responsive gui. The same is achievable with a less dubious implementation
where a graphical user interface simply has a lot of concurrently animated
components.

NB: depending on your computer specs the two millisecond threshold may have
to be set lower.

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Jan 6, 2016 9:31 AM, "Jonathan Wilkes"  wrote:

> Are there more than two people (matju and Miller) who understand the
> _current_ design?
>
> -Jonathan
>
> On Wednesday, January 6, 2016 12:00 AM, Ivica Ico Bukvic 
> wrote:
>
>
> The following is going somewhat OT but nonetheless based on this very
> interesting topic: application framerate is no more deterministic than the
> proposed idea. Just because monitor refreshes at 60Hz doesn't mean the app
> will do the same or consistently. Yet, pegging GUI updates at 60Hz (think
> speedlim-like behavior) despite all the loose ends will undoubtedly provide
> improved responsiveness over a GUI where one can send sub-millisecond
> change requests, most of which will never see the light of the day, despite
> eating up tons of CPU and in all likelihood bringing it down to its knees.
>
> On 1/4/2016 9:32 PM, Jonathan Wilkes wrote:
>
> Having an animation method allows GUI-side optimizations that aren't
> possible when the animation is smeared across the socket/parser/eval'er.
>
> Determinism: GUI rendering isn't deterministic, at least not in the way
> Pd's
> scheduler is.  For example, how could the GUI (tcl/tk or otherwise) even
> know that it missed a deadline?
>
> I guess the simple API I'm toying with is "stretching the accordion" so to
> speak, and potentially showing the cracks more explicitly with a longer
> running animation than can currently be seen in Pd's GUI.  But that can be
> remedied, either by recursively halving a single animation into smaller
> ones,
> or just giving up and using [line].
>
> The greater benefit is that more elegant types of visual feedback become
> possible without being discarded out of hand due to their potential for
> audio interruption.
>
> -Jonathan
>
> On Monday, January 4, 2016 5:20 PM, Ivica Ico Bukvic 
>  wrote:
>
>
> On 1/3/2016 3:24 PM, Jonathan Wilkes wrote:
>
> It's actually way more simplistic than that-- just an "animate" method
> that
> wraps around whatever attribute is available to the drawing command.  All
> I'll have is a ramp time, an optional delay time, and an optional easing
> curve.
> That will make it a bit like a [vline~] for GUI side animation.
>
> I'm using the web animations API because it makes things very simple, even
> to do complex things like animating path data.
>
> The idea is that this would open up some modest visualization
> opportunities
> that are otherwise too cpu intensive.  For example, if you're animating
> using [line] the socket messages can quickly get in the way of the audio.
>
>
> Will you at some point drown the CPU? Sure, but that is no different than
> a million of other ways of doing the same. OTOH, implementing the animation
> this way helps you ensure that your animation remains in sync with the
> audio, which to me seems much better gain than a potential CPU/socket
> overhead may be a shortcoming.
>
> There could be some very cool ways of filtering gui messages, as well
> (short of getting rid of the socket-based communication in favor of a
> shared memory/multithreaded design). For instance, your animation object
> could be given the screen refresh rate and therefore it would not send out
> a message via a socket unless a desired frame-worth of time has transpired
> since the last message was sent. This would do wonders not just in terms of
> animation, but also the overall gui responsiveness, if implemented
> system-wide.
>
> Best,
>
> Ico
>
>
>
> -Jonathan
>
>
>
>
>
>
>
>
> On Sunday, January 3, 2016 1:08 PM, Ivica Ico Bukvic 
>   wrote:
>
>
> I think it may make sense in addition to having a one-shot-independent
> animations that have no guarantee of staying in sync with the audio (e.g.
> these could be useful for mouse-over button animations) that your animation
> object can also receive a decimal value between its originator and
> destination, allowing for each keyframe to be a whole number. So, 0-1 would
> interpolate between the starting state and first keyframe, 1-2 between
> first and second keyframes, etc., and thus allow pd to use its timing
> mechanism to project changes in animation state via a line object, a
> counter or something similar. IIRC most (all?) HTML5-based animations can
> be triggered as independent events or can be given a specific percentage
> value. The one-shot object could i

Re: [PD] [PD-announce] ANN: pd-l2ork version 20151219 now available

[Ivica Bukvic]

OK, I think I narrowed it down to my Skylake/Haswell TSX improvement in
respect to pthreads. I forgot to update the variable on trylock. Now,
everything works as it should. I will reupload a new build with this
important fix shortly. In the meantime, you can pull the latest git and
build only core pd and overwrite /usr/bin/pd-l2ork and have it all
(hopefully) work. Hope this helps!

On Tue, Dec 22, 2015 at 9:06 PM, Ivica Ico Bukvic  wrote:

> Thank you for the report, Antonio.
>
> I am not sure what is going on with pix_image. The build used the latest
> git version of Gem, so this may be a question for IOhannes, although it is
> also conceivable something may be broken inside pd-l2ork.
>
> To help me get to the bottom of this, would you please try building your
> own from scratch on your machine using the single-line install command (as
> per online instructions) and then installing and testing that one? Please
> make sure to have prerequisites for compiling installed (also provided
> online) and to use -B flag. HTH
>
> Best,
>
> Ico
>
>
> On 12/22/2015 8:49 PM, Antonio Roberts wrote:
>
>> i Ivica,
>>
>> Thanks for the latest release!
>>
>> I've just tried running this on Ubuntu 15.10 and when I load
>> [pix_image] pure data hangs with this error:
>>
>> pattern : /usr/lib/pd-l2ork/extra/Gem/gem_video*.so
>> dylib loading file '/usr/lib/pd-l2ork/extra/Gem/gem_videoDC1394.so'!
>> dylib loading file '/usr/lib/pd-l2ork/extra/Gem/gem_videoV4L.so'!
>> dylib loading file '/usr/lib/pd-l2ork/extra/Gem/gem_videoV4L2.so'!
>> not reloading 'image' plugins (already 4 loaded)
>> watchdog: signaling pd...
>> watchdog: signaling pd...
>> watchdog: signaling pd...
>>
>> pix_video and pix_film seem to work fine...
>>
>> On 22 December 2015 at 15:57, Ivica Bukvic  wrote:
>>
>>> Apologies for x-posting,
>>>
>>> This holiday release brings you:
>>>
>>> *-legacy flag that provides 100% backwards compatibility with iemgui
>>> objects
>>> *gfsm library
>>> *added support for $0 functionality in messages
>>> *support for Intel Haswell and Skylake CPUs
>>> *ability to use # in labels
>>> *ability to use multiple $n arguments in labels
>>> *fixed bug in keyboard autorepeat and cleaned up [key] object to support
>>> autorepeat filtering
>>> *added autotune~ external and its K12 module
>>> *synced cyclone and iem libraries
>>> *other small fixes and cosmetic improvements
>>>
>>> For a raw (unedited) changelog and a more detailed overview, please
>>> visit:
>>> https://puredata.info/downloads/Pd-L2Ork/releases/20151219
>>>
>>> To download pd-l2ork:
>>> http://l2ork.music.vt.edu/main/make-your-own-l2ork/software/
>>>
>>> NB: Currently only Ubuntu 15.10 64bit build is available, with 32bit and
>>> Raspberry Pi builds forthcoming.
>>>
>>> About Pd-L2Ork
>>> Pd-L2Ork is a fork of the ubiquitous Pure-Data focusing on improved user
>>> interface, expanded collection of externals, and an advanced SVG-enabled
>>> graphical front-end. Originally it was introduced as the core
>>> infrastructure
>>> for the Linux Laptop Orchestra (L2Ork http://l2ork.icat.vt.edu), and has
>>> since expanded to include K-12 learning module with a unique learning
>>> environment offering adaptable granularity that has been utilized in over
>>> dozen maker workshops and initiatives, including the Raspberry Pi
>>> Orchestra
>>> program for middle school children introduced in the summer 2014. Today,
>>> pd-l2ork is being developed by a growing number of international
>>> collaborators and contributors.
>>>
>>> For additional info L2Ork and pd-l2ork:
>>> http://l2ork.music.vt.edu
>>>
>>> Best,
>>>
>>> --
>>> Ivica Ico Bukvic, D.M.A.
>>> Associate Professor
>>> Computer Music
>>> ICAT Senior Fellow
>>> Director -- DISIS, L2Ork
>>> Virginia Tech
>>> School of Performing Arts – 0141
>>> Blacksburg, VA 24061
>>> (540) 231-6139
>>> i...@vt.edu
>>> www.performingarts.vt.edu
>>> disis.icat.vt.edu
>>> l2ork.icat.vt.edu
>>> ico.bukvic.net
>>>
>>> ___
>>> Pd-announce mailing list
>>> pd-annou...@lists.iem.at
>>> http://lists.puredata.info/listinfo/pd-announce
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>
>>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] [PD-announce] ANN: pd-l2ork version 20151219 now available

[Ivica Bukvic]

Apologies for x-posting,

This holiday release brings you:

*-legacy flag that provides 100% backwards compatibility with iemgui
objects
*gfsm library
*added support for $0 functionality in messages
*support for Intel Haswell and Skylake CPUs
*ability to use # in labels
*ability to use multiple $n arguments in labels
*fixed bug in keyboard autorepeat and cleaned up [key] object to support
autorepeat filtering
*added autotune~ external and its K12 module
*synced cyclone and iem libraries
*other small fixes and cosmetic improvements

For a raw (unedited) changelog and a more detailed overview, please visit:
https://puredata.info/downloads/Pd-L2Ork/releases/20151219

To download pd-l2ork:
*http://l2ork.music.vt.edu/main/make-your-own-l2ork/software/
*

NB: Currently only Ubuntu 15.10 64bit build is available, with 32bit and
Raspberry Pi builds forthcoming.

About Pd-L2Ork
Pd-L2Ork is a fork of the ubiquitous Pure-Data focusing on improved user
interface, expanded collection of externals, and an advanced SVG-enabled
graphical front-end. Originally it was introduced as the core
infrastructure for the Linux Laptop Orchestra (L2Ork http://l2ork
.icat.vt.edu), and has since expanded to include K-12 learning module with
a unique learning environment offering adaptable granularity that has been
utilized in over dozen maker workshops and initiatives, including the
Raspberry Pi Orchestra program for middle school children introduced in the
summer 2014. Today, pd-l2ork is being developed by a growing number of
international collaborators and contributors.

For additional info L2Ork and pd-l2ork:
http://l2ork.music.vt.edu

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
___
Pd-announce mailing list
pd-annou...@lists.iem.at
http://lists.puredata.info/listinfo/pd-announce
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

[Ivica Bukvic]

Pd is a programming language and I cannot think of any long-lived language
where things did not become deprecated and/or required older code authors
to make minor changes to ensure it works on newer versions of the same
language. I think cyclone would do well to follow this mantra and by doing
so gain greater nimbleness in terms of development. Besides, given Pd's
patches are plain text files designed to be easily parsed, most such
changes could be addressed by a simple shell script that updates/retrofits
old patches, as needed. In the latest version of pd-l2ork I've added
-legacy flag which reconciles inconsistency with the iemgui object
positioning, similar approach could be made with these, although this will
likely increase maintenance overhead and thus diminish the aforesaid
nimbleness.

On Tue, Dec 22, 2015 at 9:51 AM, katja  wrote:

> Hello Alexandre, Fred Jan, pd list,
>
> It makes me sad to see your earlier productive collaboration on
> Cyclone stagnating with this dispute about the purpose. Between 2005 -
> 2015 the purpose of Cyclone has been determined more by what it was
> than by what it should be, by lack of human resources [1]. With the
> recent increased effort of testing, fixing and innovation there's an
> opportunity to redefine intentions and ambitions. Let's try to figure
> out a generic approach where backward compatibility doesn't conflict
> with MaxMSP compatibility and innovation, so anyone can contribute to
> the project according to their skill, interest and ambition.
>
> My proposal would be to sacrifice forward compatibility of older
> versions if needed. Classes which pose the compatibility dilemma may
> be made to operate in multiple modes. Sometimes this can be achieved
> by message, and when the number or type of inlets / outlets are
> concerned (like average~) it can be achieved with creation arguments.
>
> Now you have to decide which is the default behavior. With decades
> worth of Pd patches in mind it seems logical to keep the original
> Cyclone behavior as default and offer the MaxMSP compatible mode as an
> alternative. The help patch demonstrates how to use the newly
> developed mode. A class setup message can advertise it too.
>
> There's always this caveat with introducing new message selectors and
> creation arguments: old versions of the class don't support them so
> you could still end up with broken patches. But this is less
> problematic than backward incompatibility. The class help patch must
> give clear information about the version where new functionality was
> introduced, and anyone who applies it in a distributed Pd patch can
> inform the user about version requirements. No spurious malfunctions,
> but at worst a clear hint to upgrade.
>
> You may wonder what is my own involvement with Cyclone. At the moment,
> none apart from following the discussion. Earlier this year I spent a
> few months developing Makefile.pdlibbuilder as a generic build system
> for Pd libs. Replacing the indecipherable build system of Cyclone was
> the ultimate test case for this work, and it helped speed up Fred
> Jan's work on the library. I became aware how big a project it really
> is. It could use the love and care of more people besides Alexandre
> and Fred Jan.
>
> Katja
>
> [1].
> Cyclone (part of miXed) was unfortunately abandoned by it's original
> author Krzysztof Czaja after 2005. The ambitions with this wonderful
> project were then in practice scaled down to fixing bugs in the alpha
> versions, as illustrated by the commit history of it's SVN repository
>
> http://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/miXed/cyclone/
> .
>
> On Mon, Dec 21, 2015 at 6:26 PM, Alexandre Torres Porres
>  wrote:
> >
> > 2015-12-15 16:22 GMT-02:00 Fred Jan Kraan :
> >>
> >> Hi Alexandre,
> 
>  Compatibility is limited to a very old version of Max/MSP.
> >>>
> >>>
> >>> That really confused me, as a Max 7 user...
> >>
> >>
> >> Why? If any version of Max/MSP looks like Pd, it is 4.6 (or maybe
> earlier
> >> versions, but I don't have access to those...).
> >
> >
> > Because it is not a matter on how it "looks", and Max 7 is still the same
> > patching environment, it's not like it changed and lost compatibility,
> hence
> > I'm using both Max 7 and cyclone and I'm happy about it.
> >
> > It's not like Max 7 killed and broke backwards compatibilty with earlier
> > versions and patches. So we don't have to consider it as having to be
> tied
> > to 4.6..
> >
> > Perhaps you mean we'll never be able to come close to what Max 7 is now
> in
> > general. But I don't think that was ever possible and the purpose of
> cyclone
> > was not to make a clone of the Max/MSP Software.
> >
> > I think this is a very serious and sensitive topic, as the purpose of
> > cyclone is not being really considered in your point of view, and this
> might
> > interferes with the purpose, or even kill it...
> >
> 
>  For me this makes backward compatibility more important
>  than 

Re: [PD] What is the purpose of iemgui_raute2dollar

[Ivica Bukvic]

I think it increases the length of the string and therefore requires string
resizing, possibly causing other problems down the road...

On Sun, Nov 1, 2015 at 11:57 PM, Jonathan Wilkes  wrote:

> What's the problem with simply backslashing the dollar sign before sending
> the message to Pd?
>
> -Jonathan
> On Sunday, November 1, 2015 11:04 PM, Miller Puckette 
> wrote:
>
>
> This does need fixing... it's a primitive escaping mechanism which needs to
> be replaced with a "correct" one.  Unfortunately there are various places
> in the code that escape stuff in various ways (to get strings past
> the TCL parser or the Pd parser) and it's never been thought about in a
> unified way.
>
> cheers
> Miller
>
> On Sun, Nov 01, 2015 at 10:57:42PM -0500, Ivica Bukvic wrote:
> > Right, but this function does not do that, it explicitly replaces # with
> $.
> > What does # have to do with anything? Are you saying # is being
> substituted
> > for $ to preserve it? Even so, this still makes no sense because if you
> > create an iemgui object (pick one), then add a label with only a "#" in
> it.
> > Once you click apply, you get $ on the label instead. Reopening
> properties
> > provides you with a label that is equal to $, so  this sounds like a bug
> to
> > me that does some sort of one-way mangling that needs to be fixed and
> more
> > so, it seems to me there should be a different ascii character used to
> > preserve $, one that does not exist in the regular text-based ascii
> > chars... e.g. in pd-l2ork we use \t to substitute for \n and thus
> preserve
> > endlines in comments and other places.
> >
> > On Sun, Nov 1, 2015 at 10:33 PM, Jonathan Wilkes 
> wrote:
> >
> > > Because Pd's parser is likely to eat up a "$" followed by a number as a
> > > banking
> > > fee to pay the cost of sending messages.  :)
> > >
> > > Send this from the GUI:
> > > (canvas_addy) obj 0 0 clip $1 $2
> > >
> > > and it becomes this in Pd:
> > > [clip 0 0]
> > >
> > > There's also sys_decodeddialog/sys_encodedialog that is used for
> > > canvas_find.
> > >
> > > Additionally, I think you may have added another parser inside s_main
> > > to separate filenames in Pd-l2ork (although that one doesn't have
> anything
> > > to do with dollarsigns).
> > >
> > > I have not yet decided where I want to add my own parser for the GUI
> port.
> > > I think a Pratt parser for message-box math would be neat.
> > >
> > > -Jonathan
> > >
> > >
> > >
> > > On Sunday, November 1, 2015 9:38 PM, Ivica Bukvic  wrote:
> > >
> > >
> > > I presume this may pertain primarily to IOhannes and Miller,
> > >
> > > I am trying to figure out what is the purpose of raute2dollar in iemgui
> > > objects? On an obvious level the function replaces # with an $ in a
> send,
> > > receive, and label symbols. Why is this necessary? Personally, I cannot
> > > think of a reason why it would be, but then again, I may very well be
> > > missing something...
> > >
> > > Best,
> > >
> > > Ico
> > >
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > > http://lists.puredata.info/listinfo/pd-list
>
>
>
> > >
> > >
> > >
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] Fwd: What is the purpose of iemgui_raute2dollar

[Ivica Bukvic]

Forgot to include pd-list and l2ork-dev list...

-- Forwarded message --
From: Ivica Bukvic 
Date: Mon, Nov 2, 2015 at 12:01 AM
Subject: Re: [PD] What is the purpose of iemgui_raute2dollar
To: Miller Puckette 


So, I am about to commit a 'fix' in pd-l2ork where one can now have labels
(for gatoms and arrays as well) where escaped $ is converted into ASCII
0x01 (SOH). This seems to side-step the issue for the time-being. Does this
affect other objects?

The ideal fix would be using negative ascii values (e.g. -0x80) but those
don't seem to cut the mustard once they are received by tcl/tk...

Best,

Ico

On Sun, Nov 1, 2015 at 11:04 PM, Miller Puckette  wrote:

> This does need fixing... it's a primitive escaping mechanism which needs to
> be replaced with a "correct" one.  Unfortunately there are various places
> in the code that escape stuff in various ways (to get strings past
> the TCL parser or the Pd parser) and it's never been thought about in a
> unified way.
>
> cheers
> Miller
>
> On Sun, Nov 01, 2015 at 10:57:42PM -0500, Ivica Bukvic wrote:
> > Right, but this function does not do that, it explicitly replaces # with
> $.
> > What does # have to do with anything? Are you saying # is being
> substituted
> > for $ to preserve it? Even so, this still makes no sense because if you
> > create an iemgui object (pick one), then add a label with only a "#" in
> it.
> > Once you click apply, you get $ on the label instead. Reopening
> properties
> > provides you with a label that is equal to $, so  this sounds like a bug
> to
> > me that does some sort of one-way mangling that needs to be fixed and
> more
> > so, it seems to me there should be a different ascii character used to
> > preserve $, one that does not exist in the regular text-based ascii
> > chars... e.g. in pd-l2ork we use \t to substitute for \n and thus
> preserve
> > endlines in comments and other places.
> >
> > On Sun, Nov 1, 2015 at 10:33 PM, Jonathan Wilkes 
> wrote:
> >
> > > Because Pd's parser is likely to eat up a "$" followed by a number as a
> > > banking
> > > fee to pay the cost of sending messages.  :)
> > >
> > > Send this from the GUI:
> > > (canvas_addy) obj 0 0 clip $1 $2
> > >
> > > and it becomes this in Pd:
> > > [clip 0 0]
> > >
> > > There's also sys_decodeddialog/sys_encodedialog that is used for
> > > canvas_find.
> > >
> > > Additionally, I think you may have added another parser inside s_main
> > > to separate filenames in Pd-l2ork (although that one doesn't have
> anything
> > > to do with dollarsigns).
> > >
> > > I have not yet decided where I want to add my own parser for the GUI
> port.
> > > I think a Pratt parser for message-box math would be neat.
> > >
> > > -Jonathan
> > >
> > >
> > >
> > > On Sunday, November 1, 2015 9:38 PM, Ivica Bukvic  wrote:
> > >
> > >
> > > I presume this may pertain primarily to IOhannes and Miller,
> > >
> > > I am trying to figure out what is the purpose of raute2dollar in iemgui
> > > objects? On an obvious level the function replaces # with an $ in a
> send,
> > > receive, and label symbols. Why is this necessary? Personally, I cannot
> > > think of a reason why it would be, but then again, I may very well be
> > > missing something...
> > >
> > > Best,
> > >
> > > Ico
> > >
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > > http://lists.puredata.info/listinfo/pd-list
> > >
> > >
> > >
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] What is the purpose of iemgui_raute2dollar

[Ivica Bukvic]

Right, but this function does not do that, it explicitly replaces # with $.
What does # have to do with anything? Are you saying # is being substituted
for $ to preserve it? Even so, this still makes no sense because if you
create an iemgui object (pick one), then add a label with only a "#" in it.
Once you click apply, you get $ on the label instead. Reopening properties
provides you with a label that is equal to $, so  this sounds like a bug to
me that does some sort of one-way mangling that needs to be fixed and more
so, it seems to me there should be a different ascii character used to
preserve $, one that does not exist in the regular text-based ascii
chars... e.g. in pd-l2ork we use \t to substitute for \n and thus preserve
endlines in comments and other places.

On Sun, Nov 1, 2015 at 10:33 PM, Jonathan Wilkes  wrote:

> Because Pd's parser is likely to eat up a "$" followed by a number as a
> banking
> fee to pay the cost of sending messages.  :)
>
> Send this from the GUI:
> (canvas_addy) obj 0 0 clip $1 $2
>
> and it becomes this in Pd:
> [clip 0 0]
>
> There's also sys_decodeddialog/sys_encodedialog that is used for
> canvas_find.
>
> Additionally, I think you may have added another parser inside s_main
> to separate filenames in Pd-l2ork (although that one doesn't have anything
> to do with dollarsigns).
>
> I have not yet decided where I want to add my own parser for the GUI port.
> I think a Pratt parser for message-box math would be neat.
>
> -Jonathan
>
>
>
> On Sunday, November 1, 2015 9:38 PM, Ivica Bukvic  wrote:
>
>
> I presume this may pertain primarily to IOhannes and Miller,
>
> I am trying to figure out what is the purpose of raute2dollar in iemgui
> objects? On an obvious level the function replaces # with an $ in a send,
> receive, and label symbols. Why is this necessary? Personally, I cannot
> think of a reason why it would be, but then again, I may very well be
> missing something...
>
> Best,
>
> Ico
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] What is the purpose of iemgui_raute2dollar

[Ivica Bukvic]

I presume this may pertain primarily to IOhannes and Miller,

I am trying to figure out what is the purpose of raute2dollar in iemgui
objects? On an obvious level the function replaces # with an $ in a send,
receive, and label symbols. Why is this necessary? Personally, I cannot
think of a reason why it would be, but then again, I may very well be
missing something...

Best,

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

Re: [PD] Coll object Was: cartopol~ and poltocar~

[Ivica Bukvic]

Threaded coll does the same because IIRC it enqueues events it cannot
execute until the file is loaded, except, this makes it fall out of sync
with the rest of the system in that case, but then again that is why coll
has "done loading bang" outlet.

Also, I think what will test Max's threaded nature (or not) is loading a
huge coll file with small signal vector size and seeing if it drops
samples. If it doesn't, unless there are fundamental differences in the
audio engine between Pd and Max , this would suggest it is threaded.
Another (easier?) way is to ask someone at Cycling74 :-)

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 17, 2015 10:59 AM, "Fred Jan Kraan"  wrote:

> Hi Jonathan,
>
> > Hi Fred Jan,
> > I suppose what I am asking is if the read/write bang outlet happens
> > depth-first
> > in Max, or not.
>
> The test patch in Max 5 looked more or less like this:
> [bang(
>  |
> [t b b]
>  |\
>  |[read test.coll(
>  | |
> [dump( |
>  \ /
>  [coll]
>   |  |
>  [print]
>
> [coll] and [print] have only one inlet. The right line is connected to
> the third outlet. A collection (100 pairs) is present in the test.coll.
> The bang is printed first, the list after that.
>
> If I interpret this correctly, the [read test.coll( is executed depth
> first. Just like in cyclone.
>
> >
> > If it does not, then it means Max _is_ sacrificing predictability for
> > performance
> > in that case.  As long as we can predict that it will not crash, I think
> > at least having that option would be important for compatibility.
> >
> > -Jonathan
> >
> >
> Fred Jan
>
> >
> >
> >
> > On Saturday, October 17, 2015 7:21 AM, Fred Jan Kraan
> >  wrote:
> >
> >
> >
> >
> > On 2015-10-17 06:38 AM, Jonathan Wilkes via Pd-list wrote:
> >>
> >> Hi Ivica,
> >>
> >> When we discussed the threading feature before, I advocated against it
> >> since
> >> it breaks determinism.
> >
> > There is an other reason for not adding threading to the coll object. In
> > the past I did some testing and found it a quite convoluted object. It
> > allows several types of indices (float, symbol) and has messages
> > operating on only these subsets. I tried to document this in the help
> > patch.
> > Large collections and threading may be useful, but better suited for an
> > object with a more consistent set of operations, and just one key type
> > at a time to make results more predictable.
> >>
> >> However, the Max/MSP documentation (as well as the outlet interface
> > itself)
> >> suggests that Max's implementation is threaded, too.  Why else would you
> >> need a bang to signal when it has finished reading the file, for
> example?
> >>
> >> Can someone test how it works in practice in Max?
> >
> > The testing I did was for functionality, and I found cyclone/coll was
> > very much like Max/coll. Large collection loading was not in scope.
> >>
> >> I'm in favor of the default behavior for the sake of
> >> backwards-compatibility within
> >> Pd.  But if Max is actually threading the reads/writes, that would make
> >> this an
> >> important general feature for Max compatibility.
> >
> > Compatibility is important, but not at any price. There are several
> > objects in Max and cyclone which are troubled by
> > 'Swiss-army-knife-syndrome'. Coll is certainly one of them. This makes
> > improving it low priority for me (with the exception for crashing
> issues).
> > Large collection support can be better implemented with a clear,
> > ortogonal operation set in a new object.
> >>
> >> -Jonathan
> >>
> > The latest source is in the SVN repository and at
> > http://puredata.info/downloads/cyclone/releases
> > <http://puredata.info/downloads/cyclone/releases>(you can ignore the
> > '(unreleased)' postfix. It refuses to go away for now). It contains
> > several bug-fixes and help-patches based on the Pd-l2ork versions.
> > Current planning is to leave the SVN repository  as it is now and start
> > a Git repository based on the good work of IOhannes. But for now this is
> > just planning.
> >
> > Greetings,
> >
> > Fred Jan
> >
> >
> >>
&

Re: [PD] cartopol~ and poltocar~

[Ivica Bukvic]

The pd-l2ork implementation makes sure that by default coll is non-threaded
and therefore fully backwards compatible. Only if you give it an optional
argument 1 does it actually instantiate as a threaded object. FWIW, in
L2Ork we cannot function without it being threaded as in some of the pieces
you have gestural trackers that capture up to 50 events/entries per second
and when reloaded from HD they consist of hundreds if not several thousand
entries.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 17, 2015 12:42 AM, "Jonathan Wilkes"  wrote:

>
> Hi Ivica,
>
> When we discussed the threading feature before, I advocated against it
> since
> it breaks determinism.
>
> However, the Max/MSP documentation (as well as the outlet interface
> itself)
> suggests that Max's implementation is threaded, too.  Why else would you
> need a bang to signal when it has finished reading the file, for example?
>
> Can someone test how it works in practice in Max?
>
> I'm in favor of the default behavior for the sake of
> backwards-compatibility within
> Pd.  But if Max is actually threading the reads/writes, that would make
> this an
> important general feature for Max compatibility.
>
> -Jonathan
>
>
>
>
> On Friday, October 16, 2015 11:50 PM, Ivica Bukvic  wrote:
>
>
> cool = coll
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> Ico.bukvic.net <http://ico.bukvic.net/>
> On Oct 16, 2015 11:48 PM, "Ivica Bukvic"  wrote:
>
> I am sure this has been covered on this list before--if it is not too much
> of a trouble where can one get the new version of cyclone?
> Also, there are some improvements on pd-l2ork side of things that I've
> implemented that may detract from Max behavior but also offers other
> benefits. For instance, coll object can be threaded and as such allows
> loading of large files without dropping samples, albeit at the expense of
> determinacy, so one in these cases must rely on outputting done loading
> bang signal before working with the cool object. This option is fully
> backwards compatible and the default behavior is non-threaded. It would be
> great if we could have those merged so that we don't have to maintain two
> separate versions of the cyclone library.
> Best,
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> Ico.bukvic.net <http://ico.bukvic.net/>
> this has been corrected in the new cyclone library
>
> actually, both cartopol~ and poltocar~ were "wrong" in the same way, but
> for extended 0.42 only poltocar~ was corrected, this incomplete fix ended
> up ruining spectral processing that was actually working before that.
>
> get the new cyclone, many objects are being corrected
>
> cheers
>
> 2015-10-16 18:14 GMT-03:00 Gilberto Agostinho via Pd-list <
> pd-list@lists.iem.at>:
>
> Just a little update: the problem is with [cartopol~], its rightmost
> outlet is outputting the correct value multiplied by -1.
>
>
> On 16/10/15 22:55, Gilberto Agostinho wrote:
>
> Hello,
>
> I believe I found a bug with the objects [cartopol~] and [poltocar~].
> Basically, if I would connect both outlets of [cartopol~] to the inlets of
> [poltocar~], I would expect to receive the same values as I would input.
> The problem is that the output of the second outlet of [poltocar~] is
> multiplied by -1! I tested this with both Pd 0.46.5 and pd-extended 0.43.4
> (and this bug isn't present in Pd-l2Ork).
>
> Here is an image of the problem:
> http://s1.postimg.org/bs79w4d5b/Screenshot_from_2015_10_16_22_50_23.png
>
> Is this a known bug?
>
> Cheers,
> Gilberto
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] cartopol~ and poltocar~

[Ivica Bukvic]

cool = coll

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 16, 2015 11:48 PM, "Ivica Bukvic"  wrote:

> I am sure this has been covered on this list before--if it is not too much
> of a trouble where can one get the new version of cyclone?
>
> Also, there are some improvements on pd-l2ork side of things that I've
> implemented that may detract from Max behavior but also offers other
> benefits. For instance, coll object can be threaded and as such allows
> loading of large files without dropping samples, albeit at the expense of
> determinacy, so one in these cases must rely on outputting done loading
> bang signal before working with the cool object. This option is fully
> backwards compatible and the default behavior is non-threaded. It would be
> great if we could have those merged so that we don't have to maintain two
> separate versions of the cyclone library.
>
> Best,
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> Ico.bukvic.net
> this has been corrected in the new cyclone library
>
> actually, both cartopol~ and poltocar~ were "wrong" in the same way, but
> for extended 0.42 only poltocar~ was corrected, this incomplete fix ended
> up ruining spectral processing that was actually working before that.
>
> get the new cyclone, many objects are being corrected
>
> cheers
>
> 2015-10-16 18:14 GMT-03:00 Gilberto Agostinho via Pd-list <
> pd-list@lists.iem.at>:
>
>> Just a little update: the problem is with [cartopol~], its rightmost
>> outlet is outputting the correct value multiplied by -1.
>>
>>
>> On 16/10/15 22:55, Gilberto Agostinho wrote:
>>
>>> Hello,
>>>
>>> I believe I found a bug with the objects [cartopol~] and [poltocar~].
>>> Basically, if I would connect both outlets of [cartopol~] to the inlets of
>>> [poltocar~], I would expect to receive the same values as I would input.
>>> The problem is that the output of the second outlet of [poltocar~] is
>>> multiplied by -1! I tested this with both Pd 0.46.5 and pd-extended 0.43.4
>>> (and this bug isn't present in Pd-l2Ork).
>>>
>>> Here is an image of the problem:
>>> http://s1.postimg.org/bs79w4d5b/Screenshot_from_2015_10_16_22_50_23.png
>>>
>>> Is this a known bug?
>>>
>>> Cheers,
>>> Gilberto
>>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] cartopol~ and poltocar~

[Ivica Bukvic]

I am sure this has been covered on this list before--if it is not too much
of a trouble where can one get the new version of cyclone?

Also, there are some improvements on pd-l2ork side of things that I've
implemented that may detract from Max behavior but also offers other
benefits. For instance, coll object can be threaded and as such allows
loading of large files without dropping samples, albeit at the expense of
determinacy, so one in these cases must rely on outputting done loading
bang signal before working with the cool object. This option is fully
backwards compatible and the default behavior is non-threaded. It would be
great if we could have those merged so that we don't have to maintain two
separate versions of the cyclone library.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
this has been corrected in the new cyclone library

actually, both cartopol~ and poltocar~ were "wrong" in the same way, but
for extended 0.42 only poltocar~ was corrected, this incomplete fix ended
up ruining spectral processing that was actually working before that.

get the new cyclone, many objects are being corrected

cheers

2015-10-16 18:14 GMT-03:00 Gilberto Agostinho via Pd-list <
pd-list@lists.iem.at>:

> Just a little update: the problem is with [cartopol~], its rightmost
> outlet is outputting the correct value multiplied by -1.
>
>
> On 16/10/15 22:55, Gilberto Agostinho wrote:
>
>> Hello,
>>
>> I believe I found a bug with the objects [cartopol~] and [poltocar~].
>> Basically, if I would connect both outlets of [cartopol~] to the inlets of
>> [poltocar~], I would expect to receive the same values as I would input.
>> The problem is that the output of the second outlet of [poltocar~] is
>> multiplied by -1! I tested this with both Pd 0.46.5 and pd-extended 0.43.4
>> (and this bug isn't present in Pd-l2Ork).
>>
>> Here is an image of the problem:
>> http://s1.postimg.org/bs79w4d5b/Screenshot_from_2015_10_16_22_50_23.png
>>
>> Is this a known bug?
>>
>> Cheers,
>> Gilberto
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>


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

Re: [PD] percolate binaries

[Ivica Bukvic]

munger~ variant disis_munger~ is present inpd-l2ork by default. But the
rest has not been integrated yet. There is source for Linux externals
(flext version). Alas, the last time I checked munger~ was broken. HTH

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
Ico.bukvic.net
On Oct 7, 2015 2:33 PM, "Joel Matthys"  wrote:

> As far as I know, percolate binaries just aren't available for Pd anymore.
>
> But rtcmix~ has all of the STK instruments and several other physical
> models as well. It's available for Linux and OSX, in Deken and here:
> http://puredata.info/Members/jwmatthys/
>
> You can read documentation on the RTcmix language here: http://rtcmix.org/
>
> Joel
>
> On 10/06/2015 03:08 AM, Jeppi Jeppi wrote:
>
> Hi all,
> I am looking for the last Percolate binaries (specifically, if available,
> for Win7 & Osx Mavericks). Has anyone compiled them for such platforms? It
> seems pretty old. The one I have for Osx states "wrong architecture" and
> won't load. Besides, any other woodwind physical model would do, but I
> didn't find anything else for Pd.
>
> Thanks in advance
> josep
>
>
> ___pd-l...@lists.iem.at mailing 
> list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] getting [inlet~] to accept data

[Ivica Bukvic]

While I don't know much about the draw group yet, it is conceivably
possible the order by which inlets are created and depending on what kind
they are could have something to do with it.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
On Sep 19, 2015 11:11 PM, "Jonathan Wilkes via Pd-list" <
pd-list@lists.iem.at> wrote:

> It doesn't look to be much different atm.
>
> In fact, I can't even figure out how subpatches actually reorder their
> inlets and outlets when you add new [inlet] and [outlet] objects inside
> them.  I have an
> object in Pd-l2ork called [draw group], which is essentially just a
> subpatch
> with an inlet-- to set graphical attributes-- and an outlet-- to receive
> event
> notifications.  Thing is, my extra outlet will appear as the leftmost
> outlet when I
> load the patch, while my extra inlet will always be the furthest to the
> right (like
> with the pointer inlet in [append].)
>
> Looking at the reordering code for inlets vs. outlets, I can't see any
> obvious
> differences.
>
> -Jonathan
>
>
>
> On Saturday, September 19, 2015 10:50 PM, Matt Barber 
> wrote:
>
>
> I worked on this for a while in 2008. A big part of the problem is that
> the architecture for first/main inlets is quite different from generic
> inlets, which do not respond to both signals and messages. [inlet~] does
> (or at least is supposed to) promote floats to signals, but it won't pass
> other kinds of messages; and it seemed like too deep a problem to be solved
> without a pretty serious overhaul. This was a number of years ago and
> things may have changed since then, but I don't think so (though I'd be
> glad to be wrong).
>
> Matt
>
> On Fri, Sep 18, 2015 at 11:04 AM, Christof Ressi 
> wrote:
>
> I was wondering about that too! After a quick search in the mailarchives
> I've found this discussion from 2008:
> http://lists.puredata.info/pipermail/pd-list/2008-06/062895.html
>
> @IOhannes: What's the state now? How difficult would it be to make an
> [inlet~] external which, for example, passes signals to a left outlet and
> all messages (also floats!) to a right outlet. Or which passes everything
> it receives and then you could use [route~] from zexy to separate signals
> from messages?
>
>
>
> *Gesendet:* Freitag, 18. September 2015 um 12:49 Uhr
> *Von:* "Liam Goodacre" 
> *An:* "pd-list@lists.iem.at" 
> *Betreff:* [PD] getting [inlet~] to accept data
> Many objects (ie. [osc~]) have a sort of a hybrid inlet which accepts both
> signal and data input. However, the [inlet~] object seems to reject data.
> If I wanted to build an abstraction with an [inlet~] that accepts both
> signal and data, is there any other way?
> ___ Pd-list@lists.iem.at
> mailing list UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] ANN: pd-l2ork version 20150917 now available

[Ivica Bukvic]

OK, I seem to have found the culprit. A new version 20150919 of the 32bit,
64bit, and Raspberry Pi builds is now available. Please let me know if this
fixes your problem. Thank you.

On Sat, Sep 19, 2015 at 12:48 PM, Ivica Bukvic  wrote:

> Oops, looks like I missed a file. Lemme investigate.
>
> Best,
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> i...@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> On Sep 19, 2015 12:33 PM, "Jonghyun Kim"  wrote:
>
>> I got this err when installing. Sure I installed the all listed
>> dependencies.
>> Ubuntu 14.10 64bit
>> Pre-Installed Pd Vers:
>> Pd 0.45.5
>> Pd-extended 0.43.4
>> 
>> $ sudo dpkg -i pd-l2ork*deb
>> (Reading database ... 466217 files and directories currently installed.)
>> Preparing to unpack pd-l2ork-x86_64-20150917.deb ...
>> Unpacking pd-l2ork (20150917) ...
>> dpkg: error processing archive pd-l2ork-x86_64-20150917.deb (--install):
>> trying to overwrite '/usr/include/Gem/Gem/WorkerThread.h', which is also
>> in package pd-extended 0.43.4-1~trusty1
>> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
>> Errors were encountered while processing:
>> pd-l2ork-x86_64-20150917.deb
>> $
>> ===
>>
>> thanks,
>> akntk
>>
>> On Sat, Sep 19, 2015 at 4:19 AM, Ivica Ico Bukvic  wrote:
>>
>>> Hey Patrick! Hope all is well. Please see my responses below.
>>>
>>> On 9/18/2015 1:31 PM, Pagano, Patrick wrote:
>>>
>>>> Ico
>>>> Thanks so much. I am on ubuntu64 so I will install it. It does not
>>>> interfere with Vanilla does it?
>>>>
>>>
>>> Exactly. The two can now happily coexist next to each other. Just make
>>> sure not to mix and match externals compiled for one with the other (even
>>> though the jury is still out whether pd-l2ork can handle vanilla externals
>>> without crashing, something I suspect is likely but not proven). Either
>>> way, this should not be necessary since pd-l2ork ships with many (most?)
>>> externals included.
>>>
>>>
>>>> Also, I was chatting with our newest Research dean at the college of
>>>> fine arts student meet and greet and your name came up. Tony Kolenic😎
>>>>
>>>
>>> Very cool! Well, that explains why my ears were burning earlier today
>>> ;-) Kidding aside, Tony is a really cool guy. Please tell him I said hi.
>>>
>>> Best,
>>>
>>> Ico
>>>
>>>
>>>
>>>> Sent from my iPhone
>>>>
>>>> On Sep 18, 2015, at 1:40 AM, Ivica Ico Bukvic  wrote:
>>>>>
>>>>> Apologies for x-posting,
>>>>>
>>>>> Following over dozen minor releases, yesterday pd-l2ork team has
>>>>> unveiled our latest major release, version 20150917. Release highlights
>>>>> include:
>>>>>
>>>>> Release highlights:
>>>>>
>>>>> *Expanded K12 module
>>>>> *Pd-L2Ork can now coexist with other releases without any package
>>>>> conflicts
>>>>> *Drawing optimizations
>>>>> *New convenience functions, like comments with endlines and labels
>>>>> with spaces
>>>>> *Comprehensive Raspberry PI GPIO with PWM and I2S/MCP3008 (for analog
>>>>> ins) support
>>>>> *New version of L2Ork-centric libcwiid library fork offering support
>>>>> for all versions of Nintendo-branded wiimotes, including the new 
>>>>> MotionPlus
>>>>> Inside, as well as the support for interleaved passthrough mode (e.g.
>>>>> MotionPlus + Nunchuk)
>>>>> *Code refactoring
>>>>> *Bunch of minor and aesthetic fixes
>>>>> *Last release (barring any major bugs) prior to the next major release
>>>>> featuring node-webkit GUI (node-webkit version is currently in alpha stage
>>>>> of development)
>>>>>
>>>>> For a changelog and a more detailed overview, please visit:
>>>>> http://puredata.info/downloads/Pd-L2Ork/releases/20150917
>>>>>
>>>>> To download pd-l2ork:
>>>>> http://l2ork.music.vt.edu/main/?page_id=56
>>>>>
&g

Re: [PD] [PD-announce] ANN: pd-l2ork version 20150917 now available

[Ivica Bukvic]

Oops, looks like I missed a file. Lemme investigate.

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
On Sep 19, 2015 12:33 PM, "Jonghyun Kim"  wrote:

> I got this err when installing. Sure I installed the all listed
> dependencies.
> Ubuntu 14.10 64bit
> Pre-Installed Pd Vers:
> Pd 0.45.5
> Pd-extended 0.43.4
> 
> $ sudo dpkg -i pd-l2ork*deb
> (Reading database ... 466217 files and directories currently installed.)
> Preparing to unpack pd-l2ork-x86_64-20150917.deb ...
> Unpacking pd-l2ork (20150917) ...
> dpkg: error processing archive pd-l2ork-x86_64-20150917.deb (--install):
> trying to overwrite '/usr/include/Gem/Gem/WorkerThread.h', which is also
> in package pd-extended 0.43.4-1~trusty1
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Errors were encountered while processing:
> pd-l2ork-x86_64-20150917.deb
> $
> ===
>
> thanks,
> akntk
>
> On Sat, Sep 19, 2015 at 4:19 AM, Ivica Ico Bukvic  wrote:
>
>> Hey Patrick! Hope all is well. Please see my responses below.
>>
>> On 9/18/2015 1:31 PM, Pagano, Patrick wrote:
>>
>>> Ico
>>> Thanks so much. I am on ubuntu64 so I will install it. It does not
>>> interfere with Vanilla does it?
>>>
>>
>> Exactly. The two can now happily coexist next to each other. Just make
>> sure not to mix and match externals compiled for one with the other (even
>> though the jury is still out whether pd-l2ork can handle vanilla externals
>> without crashing, something I suspect is likely but not proven). Either
>> way, this should not be necessary since pd-l2ork ships with many (most?)
>> externals included.
>>
>>
>>> Also, I was chatting with our newest Research dean at the college of
>>> fine arts student meet and greet and your name came up. Tony Kolenic😎
>>>
>>
>> Very cool! Well, that explains why my ears were burning earlier today ;-)
>> Kidding aside, Tony is a really cool guy. Please tell him I said hi.
>>
>> Best,
>>
>> Ico
>>
>>
>>
>>> Sent from my iPhone
>>>
>>> On Sep 18, 2015, at 1:40 AM, Ivica Ico Bukvic  wrote:

 Apologies for x-posting,

 Following over dozen minor releases, yesterday pd-l2ork team has
 unveiled our latest major release, version 20150917. Release highlights
 include:

 Release highlights:

 *Expanded K12 module
 *Pd-L2Ork can now coexist with other releases without any package
 conflicts
 *Drawing optimizations
 *New convenience functions, like comments with endlines and labels with
 spaces
 *Comprehensive Raspberry PI GPIO with PWM and I2S/MCP3008 (for analog
 ins) support
 *New version of L2Ork-centric libcwiid library fork offering support
 for all versions of Nintendo-branded wiimotes, including the new MotionPlus
 Inside, as well as the support for interleaved passthrough mode (e.g.
 MotionPlus + Nunchuk)
 *Code refactoring
 *Bunch of minor and aesthetic fixes
 *Last release (barring any major bugs) prior to the next major release
 featuring node-webkit GUI (node-webkit version is currently in alpha stage
 of development)

 For a changelog and a more detailed overview, please visit:
 http://puredata.info/downloads/Pd-L2Ork/releases/20150917

 To download pd-l2ork:
 http://l2ork.music.vt.edu/main/?page_id=56

 NB: Currently only Ubuntu 14.04 64bit build is available, with 32bit
 and Raspberry Pi builds forthcoming.

 About Pd-L2Ork
 Pd-L2Ork is a fork of the ubiquitous Pure-Data focusing on improved
 user interface, expanded collection of externals, and an advanced
 SVG-enabled graphical front-end. Originally it was introduced as the core
 infrastructure for the Linux Laptop Orchestra (L2Ork
 http://l2ork.icat.vt.edu), and has since expanded to include K-12
 learning module with a unique learning environment offering adaptable
 granularity that has been utilized in over dozen maker workshops and
 initiatives, including the Raspberry Pi Orchestra program for middle school
 children introduced in the summer 2014. Today, pd-l2ork is being developed
 by a growing number of international collaborators and contributors.

 For additional info L2Ork and pd-l2ork:
 http://l2ork.icat.vt.edu

 More about the founding author:
 http://ico.bukvic.net

 Best,

 --
 Ivica Ico Bukvic, D.M.A.
 Associate Professor
 Computer Music
 ICAT Senior Fellow
 Director -- DISIS, L2Ork
 Virginia Tech
 School of Performing Arts – 0141
 Blacksburg, VA 24061
 (540) 231-6139
 i...@vt.edu
 www.performingarts.vt.edu
 disis.icat.vt.edu
 l2ork.icat.vt.edu


 ___
 Pd-announce ma

Re: [PD] changing font size overall

[Ivica Bukvic]

Pd has per-iemgui-object and per-abstraction font settings, so changing
font size only affects non-iemgui objects in the currently focused patch
and its non-abstraction subpatches. What you may be looking for is a zoom
level which does not exist (yet). HTH

Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
i...@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
On Sep 6, 2015 7:48 AM,  wrote:

> cyrille wrote:
> 
> when i put for example -font-size 16 in the command line it doesn't have
> any effect.
>
> rolf
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] miller's gpio on rpi2modelB and the "enable" message

[Ivica Bukvic]

Are you running pd with sudo privileges?
On Aug 28, 2015 2:25 PM, "Peter P."  wrote:

> Hi list, hi J,
>
> I am better understand the GPIOs on a Raspberry Pi 2 model B using
> Miller's gpio external from pi-externs. Everything works fine so far,
> only in the help patch kindly provided by J Oliver in his posting
> http://lists.puredata.info/pipermail/pd-list/2013-04/102172.html
> the message "enable 17" is said to do the same as an
> echo "17" > /sys/class/gpio/export
> on the shell, but is has no effect, no file
> /sys/class/gpio/gpio17 is created.
>
> If I create in on the console all is fine.
>
> Does anyone else experience this?
>
> Thanks, Peter
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Wiimote external not working any more ...

[Ivica Bukvic]

Try disis_wiimote (included in pd-l2ork; source also available separately
and compatible with vanilla), unless you have one of the newer wiimote plus
controllers that may not be yet fully supported.

HTH
On Aug 8, 2015 9:17 AM, "frank"  wrote:

> Niklas Reppel  parkellipsen.de> writes:
>
> >
> > Hi everybody,
> >
> > it has been a long time since i've been toying around with my wiimote,
> > but i remember that it was'n hard to make it run.
> >
> > Now, i tried to make it functional again (on an Arch Linux system).
> > Wmgui, hcitool sca, everything works fine!
> >
> > BUT, the wiimote external doesn't (i downloaded version 0.3.2 from
> > puredata.info). It compiles fine, but discovery
> > doesn't work (again, no problem with wmgui!). Ok, i can connect with
> > explicit address. But still, only button data is
> > processed, i can't see any acceleration data or IR data ... (i can see
> > it in wmgui).
> >
> > A year ago or so, everything worked quite well ...
> >
> > Any hints ?
> >
> > Regards,
> > Nik
> >
> > ___
> > Pd-list  lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
>
> Hi Nik,
> I've had the same issues with the wiimote-object. I wasn't able to fix the
> broken  discover-mode yet, but the other stuff works again by changing the
> onoff argument type in the function name below from int to float:
> static void wiimote_report(t_wiimote*x, t_symbol*s, float onoff)
>
> I've uploaded the source here:
> https://www.dropbox.com/sh/gt5cydrkr1ja3a4/AAAOXqHRny1_3wcn9fnCDCn1a?dl=0
>
> best,
> Frank
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] compiling for Raspberry Pi 2 (was 2nd Pi 2 issue)

[Ivica Bukvic]

IIRC last time I spoke with the wiringPi author I pointed out to him how
the library was designed to make the app using it exit should the
conditions not match library's requirements (e.g. sudo access). While this
is perfectly fine when running the library through a standalone command
line application focusing solely on gpio connectivity, like the one
provided with the library, in the context of Pd it results in a crash
because such an acton results in a null pointer. His response to my report
was that it was designed that way intentionally and that he had no
intentions of changing that.

For this reason a while ago I released the disis_gpio external that
partially depends on the wiringPi library and redesigns the rest to allow
for the external to gracefully fail without crashing Pd. The disis_gpio
external is prepackaged with Pd-l2ork and its source (found on pd-l2ork's
github), together with the disis_spi external for mcp3008 A/D converter
should be fully source compatible with other flavors of Pd. HTH

Best,

Ico
On Jul 7, 2015 9:33 AM, "IOhannes m zmoelnig"  wrote:

> On 2015-07-07 06:51, Jaime E Oliver wrote:
> >>> El 06/07/2015, a las 8:52 p.m., Jaime E Oliver <
> jaime.oliv...@gmail.com> escribió:
> >>>
> >>> the externals will crash pd if it isn't opened with sudo.
> >>> J
> >> What do you mean with external crash? do you refer the wiringPi
> externals?
> > yes. you need sudo level to access the gpio with those externals and
> will crash if you don't start pd as sudo.
>
> whoever is in charge of that external should probably fix the crash.
>
> fgmasdr
> IOhannes
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] wiimote

[Ivica Bukvic]

Hi,

This is likely because you are using a newer version of the wiimote that
has motionplus embedded and the supporting libcwiid library wiimote object
relies on does not support that version. For the time being your only
choice is to use older version of the wiimote. HTH

Best,

Ico
On Jun 19, 2015 3:28 PM, "Richard Millig"  wrote:

> hi all,
>
> this is my first post here, so please give me feedback, if you need more
> information. so here's my issue:
>
> i'm trying to connect my wii motionplus with the wiimote object. after
> pressing 1 and 2 and sending the message "connect B8:AE:6E:55:35:2B" (this
> is the mac-adress, which i found out via hcitool scan), i get the following
> on my pd window:
>
> wiimote 3 is successfully connected
> wiimote: Report send error (read)
> wiimote: Read error (%scal)
> Unable to retrieve accelerometer calibration
> wiimote: Send report error (report mode)
> wiimote: could not set report mode.
> comm error
> wiimote: Mutex destroy error (rpt)
> disconnect successfull, resetting values
> mesg 8 unknown
>
> thank you for helping
> richard
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [L2Ork-dev] pd-extended/pd-l2ork not loading pngs

[Ivica Bukvic]

Not sure. Pd-l2ork always builds against the latest gem git snapshot. It is
conceivable that latest git may have introduced some kind of a change or
that your build did not have all the necessary libraries.
On May 17, 2015 4:01 PM, "Antonio Roberts"  wrote:

> I recently upgraded to Ubuntu 15.04. One of the many many problems I
> experienced is that I'm no longer able to load pngs using [pix_image].
> The only error I get when I try to do this is:
>
> [pix_image]: failed to load image 'testimage.png'
>
> Any clues as to where the problem is?
>
> Thanks,
>
> Antonio
> --
> 
> anto...@hellocatfood.com
> http://www.hellocatfood.com
> 
> ___
> L2Ork-dev mailing list
> l2ork-...@disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Granular Synthesis on liv input?

[Ivica Bukvic]

Try disis_munger~ which is a flext external that also runs on RPi and is
included with the pd-l2ork builds. The help file provides live input
example.

NB: RPi's CPU is fairly limited in terms of computational power, so it is
rather easy to choke it when increasing a number of concurrent voices.

HTH
On May 17, 2015 12:22 PM, "Pagano, Patrick" 
wrote:

>  Hi i am trying to build a granular instrument for a prototype Pd
> eurorack module
>
> I am using Pd-Vanilla and Raspberry Pi and Arduino
>
>
>  is there a patch out there that does granualr on live input i can use
> for testing the setup?
>
>
>  pp
>
>
>   *Patrick Pagano B.S, M.F.A*
> Audio and Projection Design Faculty
> Digital Worlds Institute
> University of Florida, USA
> (352)294-2020
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Fw: [PD-dev] Mouse over editing Pd patch

[Ivica Bukvic]

No, as far as the current design is concerned, as pd calculates getrect for
every object to see if the new mouse position is on top of something
clickable. For this reason, abstracting your mega-patch into subpatches
(where possible) is not only a good programming practice for the purpose of
legibility and reusability, but also for performance reasons. HTH
On Jan 7, 2015 6:19 PM, "Ed Kelly"  wrote:

> On Wednesday, 7 January 2015, 11:55, Ed Kelly 
> wrote:
>
>
>
>
> What about this...
>
> When I am editing a huge patch like the Ninja Jamm patch, where everything
> is on the same level (i.e. as few sub-patches as possible) moving the mouse
> over the patch causes a CPU spike, regardless of whether I change, move or
> connect anything or not.
>
> Could this be changed? I don't know all the guts of Pd, but if you could
> just move around the mouse pointer without
> having to wait for 20 seconds or so before you can do anything, it would
> save a lot of time.
>
> I think I heard once that any change to the patch means that Pd has to
> re-draw the entire graph. IMHO surely moving the mouse should not require
> this? I wait to be corrected!
>
> x
> Ed
>
> Ninja Jamm - a revolutionary new music remix app from Ninja Tune and
> Seeper, for iPhone and iPad
> http://www.ninjajamm.com/
>
>
> Gemnotes-0.2: Live music notation for Pure Data, now with dynamics!
> http://sharktracks.co.uk/
>
> ___
> Pd-dev mailing list
> pd-...@lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] GUI Plugins in pd-l2ork?

[Ivica Bukvic]

Unfortunately no. This is mainly because we are currently in the process of
porting the entire GUI to a different toolkit altogether which will render
plugins like these superfluous. If there is a genuine interest in zenity,
we may want to provide an interim version that supports this plugin. HTH

Best,

Ico
On Jan 5, 2015 5:51 PM, "Rafael Vega"  wrote:

> Hi,
>
> I'm giving pd-l2ork a try for the first time and I would like to use the 
> Zenity
> Gtk open/save GUI plugin. I have put the .tcl file in ~/pd-l2ork-externals
> (that directory is in pd-l2ork's path) but the open and save dialogs stay
> unchanged.
>
> Any ideas?
> Does pd-l2ork support GUI plugins?
>
> Thanks.
>
> --
> Rafael Vega
> email.r...@gmail.com
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [Bulk] gui toolkits

[Ivica Bukvic]

On Dec 24, 2014 11:49 AM, "Alessio Degani"  wrote:
>
> On 24/12/2014 06:18, Jonathan Wilkes via Pd-list wrote:
>>
>> Hi list,
>> I've been investigating other guis as possible replacements for tcl/tk
gui.  A few reasons:
>> * tk is slow to redraw
>> * no anti-aliasing except on OSX
>> * poor support for theming
>> * poor support for standard image formats
>> * binary alpha channel
>> * limited control of font properties on canvas
>> * lack of proper canvas zooming
>> * non-standard file save/open dialogs
>> * lack of common gui-toolkit tools like tooltips and rich text
>> * too much bit-rot in third-party libraries to work around all the above
>
>
> Good point.
> In my opinion, graphical stuff requires a lot of effort (in code/design
and, of course, for the portability).
> I really *LOVE* the pd (well... I prefer pd-extended :) ) graphical
philosophy: small bocks, no exploding rainbows of color. Simple and
elegant.
>
> Can be better? Probably. Especially considering the issues presented by
Jonathan. But I think that will be a huge milestone (in terms of effort).
Ok... the modular nature of pd can help a lot in order to make smooth
transitions.

Actually, it is not that much of work. Porting to tkpath took me no more
than a couple of days. Granted, tkpath is quite similar to tcl/tk but the
principle is the same. Alas, tkpath is defunct project.

The real leap in the gui will happen once/if/when networked nature of
communication between pd and tcl is replaced with threaded design. This
will solve a good chunk of determinacy issues and likely introduce new
problems, but the gui will be likely way more responsive.

>
> To the technical side, which tk?
> 1. JUCE: multiplatform

Licensing is fairly restrictive, though, in comparison to alternatives.
Benefits obvious (Max uses it).

> 2. FlowCanvas (now Ganv, http://drobilla.net/software/flowcanvas/):
technically is not a tk, but a widget for Gtkmm, but its a nice widget for
drawing "boxes and lines" (cit. Drobilla) stuff.
>
> Cheers
>
> Alessio
>
>> [CUT]
>> -Jonathan
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>
>
>
> --
> a.
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] future PD-extended development

[Ivica Bukvic]

On Dec 23, 2014 3:27 PM, "Dan Wilcox"  wrote:
>
> * starting a new thread *
>
> * responding to : *
>
>> Actually, you're simply trading one shortcoming for another, and I would
argue you're shortcoming is a lot harder to troubleshoot. If you provide a
monolithic distribution to all of your users, then reproducing their
problems becomes exponentially easier as opposed to encouraging each user
to install select externals which may clash with each other in unusual ways
that may not be apparent otherwise and then trying to backtrace and
troubleshoot their specific set up as opposed to relying on one monolithic
release that you can easily reproduce on your own computer. If we had
infinite time on this rock this may be a feasible option. As for me,
particularly considering I am doing this not because I am getting paid to
do it, monolithic approach is the way to go with the ultimate goal of
having all externals in the extra folder and without any subfolders (in
part because duplicates and buggy externals will have been weeded out).
>
>
> Technically it doesn’t matter if you want to build everything together or
install things individually. Let’s say we move the externals into separate
repos. People working with the vanilla or Pd-L2ork sources or whatever can
use git submodules or clone the sources that they need into the extras
folder. Then everything can be built together and distributed. If a PD
developer wants to change the folder structure and layout of the externals
they use and maybe conditionally drop a c file, they can easily do that
with scripting that fetches the latest version and then removes the
unneeded files. I do this in a lot of projects including libpd where we
don’t need to compile all of the vanilla sources.

All this sounds nice but the question remains who will do the add-on
scripts to customize the build process and support both approaches? Hans
did a good chunk of this for extended and I simply chose to maintain entire
build system for pd-l2ork to ensure things get built properly for
pd-l2ork's needs which was a good chunk of work. If you want to merge what
I did with pd-l2ork and populate sources with ifdefs where I added features
that are impossible to implement in the current vanilla, I am all fine with
that. With my limited time, I simply don't have the resources to do all
this work and chance having it lie stuck on SourceForge as an uncommitted
patch.

>
> Conversely, some people can still download the vanilla binary and build
an external separately or install a precompiled external.
>
> Bug-wise, things might show up now and then (as they always do), but if
we’re all pulling from the a same place, bug reports can be sent upstream
and fixed. Again, it’s easy for this model to work on Github. Judging from
the sourceforge bugtracker, the pd community is good about opening bug
reports.
>
> Also, a simple option to continue extended would be a new “Pd-extended”
that is basically Miller’s current Pd vanilla binary with precompiled
externals in the /extra folder. This is what I currently use, a few of the
precompiled externals from the last version of Pd-extended with Miller’s
latest version. If what most people want are the new features of vanilla
with GEM and a few set of other externals, then we can do that now if it’s
much easier to build those externals without downloading the massive SVN. I
have a script which does this on Linux for my UDOO board setup so I have
the 9-10 externals my old song patch set requires. This is similar to
aforementioned idea of providding all the commonly used externals in one
precompiled download.
>
> As was pointed out Hans has already established the libdir format and I
was using “standard makefiles” etc earlier to refer to that. Again, I think
what’s important is to break out the external development from the SVN into
smaller, more maintainable repos in order to more effectively coordinate
resources. None of us are getting paid, which is why it’d be nice to find a
way to make this whole think work for *all* pd development.

Indeed. If you would like to reconcile the sources between pd-l2ork's tree
and vanilla third party externals, by all means please feel free to do so
and I will gladly merge whatever does not break my build process.

Best,

Ico

>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)

[Ivica Bukvic]

On Dec 23, 2014 1:53 AM, "Dan Wilcox"  wrote:
>
> You know guys, all I’m saying is perhaps there’s a way to move forward
with the spirit of Pd-extended with the practicality of making it easy to
use the extended externals with vanilla. In no way was I trying to say what
you’re doing or not doing with pd-l2ork is wrong.
>
> This line "I assume l2ork doesn’t rely on one person testing and building
across multiple platforms?” is only asking if you’ve experienced what a
pain it is to handle that. It takes work and it’s *really* nice not to have
to rely on one or two people to manually check things. I wrote that in
comradeship assuming you agree that it’s a pain to do.
>
> I appreciate the work y’all are doing, but not everyone wants to use
pd-l2ork and you yourselves have said you have no interest in trying to
fill the role of Pd-extended.

I think you may have misunderstood me (or I may have misspoke, honestly
can't remember). Pd-l2ork is and has since its inception replaced extended
in my own work. Out of respect to the work of Hans and many others have
done with extended, as well as pd-l2ork's arguably lesser concern with
legacy stuff I never wanted to claim it will do the same for you and others
(even though as of right now I can think of a couple, mainly cosmetic
reasons why it wouldn't).

Best,

Ico

>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>> On Dec 22, 2014, at 7:06 PM, Jonathan Wilkes  wrote:
>>
>> One thing I'll add-- Pd-extended already includes within it the ability
for individual libraries to be compiled "a la carte" in the way Dan
desires.  Any library adhering to the "libdir" format will have a standard
makefile that can be used to compile the binaries.  They'll end up in the
same directory with their help patches, which means in most cases they will
create properly when the user opens the help patch (even if that library
hasn't been loaded yet).
>>
>> The idea of scripting dependencies across externals is an interesting
one.  I don't think that currently happens with Pd-extended.  But a lot of
libraries do employ [pddp/pddplink] in the documentation, so that feature
would be handy in that situation.
>>
>> Also-- I think weeding out "duplicate" externals is a bad idea, at least
the way Ivica describes it.  Many people have built patches with
Pd-extended, assuming that all the object names available at startup are
essentially like "keywords" in text-based languages.  It's unfortunate that
[lib1/foo] does the same exact thing as [lib2/bar].  But if I'm trying to
show off Pd by playing some fancy synthesizer patch which relies on
[lib1/foo], it had better work.  I'll always prefer ugly-but-works over
clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits.
>>
>> Anyway, I think there are ways to prefer certain objects or libs in the
search results, and steer new users to the more reliable and maintained set
of externals.
>>
>> -Jonathan
>>
>>
>> On Monday, December 22, 2014 5:48 PM, Ivica Bukvic  wrote:
>>
>>
>>
>> On Dec 22, 2014 10:23 PM, "Dan Wilcox"  wrote:
>> >
>> >
>> >> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes 
wrote:
>> >>
>> >> Unless you want an enormous number of patches in the wild to bit-rot,
you're going to have a "Install Pd-extended libraries" button.  If you have
that button, then presumably at least _one_ person is going to need to
build and test the whole enchilada, no?
>> >
>> >
>> > I disagree. If it’s easier to build, then it will be easier for a
number of people to test on their respective OS. I assume l2ork doesn’t
rely on one person testing and building across multiple platforms? I’ve
been in that situation already and it sucks. Much nicer to split up the
work, better still if the makefiles work and we have some scripting to
handling automation, fetching, etc for developers and volunteer testers.
>> Actually, you're simply trading one shortcoming for another, and I would
argue you're shortcoming is a lot harder to troubleshoot. If you provide a
monolithic distribution to all of your users, then reproducing their
problems becomes exponentially easier as opposed to encouraging each user
to install select externals which may clash with each other in unusual ways
that may not be apparent otherwise and then trying to backtrace and
troubleshoot their specific set up as opposed to relying on one monolithic
release that you can easily reproduce on your own computer. If we had
infinite time on this rock this may be a feasible option. As for me,
particularly considering I am doing this not because I am getting paid to
do it, monolithic approach is the way to go 

Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)

[Ivica Bukvic]

On Dec 23, 2014 1:06 AM, "Jonathan Wilkes"  wrote:
>
> One thing I'll add-- Pd-extended already includes within it the ability
for individual libraries to be compiled "a la carte" in the way Dan
desires.  Any library adhering to the "libdir" format will have a standard
makefile that can be used to compile the binaries.  They'll end up in the
same directory with their help patches, which means in most cases they will
create properly when the user opens the help patch (even if that library
hasn't been loaded yet).
>
> The idea of scripting dependencies across externals is an interesting
one.  I don't think that currently happens with Pd-extended.  But a lot of
libraries do employ [pddp/pddplink] in the documentation, so that feature
would be handy in that situation.
>
> Also-- I think weeding out "duplicate" externals is a bad idea, at least
the way Ivica describes it.  Many people have built patches with
Pd-extended, assuming that all the object names available at startup are
essentially like "keywords" in text-based languages.  It's unfortunate that
[lib1/foo] does the same exact thing as [lib2/bar].  But if I'm trying to
show off Pd by playing some fancy synthesizer patch which relies on
[lib1/foo], it had better work.  I'll always prefer ugly-but-works over
clean-but-let-me-debug-this-patch-while-everyone-sits-there-and-waits.

If the weeding is done properly, this alteration will provide adequate
feedback, as is the case with cyclone/prepend, or will simply automatically
substitute an object, e.g. clashing average implementations, of which one
is clearly superior, and yet where both implementations are near synonymous.

Also, let's not forget that extended has already done this before by
obsoleting certain libraries.

>
> Anyway, I think there are ways to prefer certain objects or libs in the
search results, and steer new users to the more reliable and maintained set
of externals.
>
> -Jonathan
>
>
> On Monday, December 22, 2014 5:48 PM, Ivica Bukvic  wrote:
>
>
>
> On Dec 22, 2014 10:23 PM, "Dan Wilcox"  wrote:
> >
> >
> >> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes 
wrote:
> >>
> >> Unless you want an enormous number of patches in the wild to bit-rot,
you're going to have a "Install Pd-extended libraries" button.  If you have
that button, then presumably at least _one_ person is going to need to
build and test the whole enchilada, no?
> >
> >
> > I disagree. If it’s easier to build, then it will be easier for a
number of people to test on their respective OS. I assume l2ork doesn’t
rely on one person testing and building across multiple platforms? I’ve
been in that situation already and it sucks. Much nicer to split up the
work, better still if the makefiles work and we have some scripting to
handling automation, fetching, etc for developers and volunteer testers.
> Actually, you're simply trading one shortcoming for another, and I would
argue you're shortcoming is a lot harder to troubleshoot. If you provide a
monolithic distribution to all of your users, then reproducing their
problems becomes exponentially easier as opposed to encouraging each user
to install select externals which may clash with each other in unusual ways
that may not be apparent otherwise and then trying to backtrace and
troubleshoot their specific set up as opposed to relying on one monolithic
release that you can easily reproduce on your own computer. If we had
infinite time on this rock this may be a feasible option. As for me,
particularly considering I am doing this not because I am getting paid to
do it, monolithic approach is the way to go with the ultimate goal of
having all externals in the extra folder and without any subfolders (in
part because duplicates and buggy externals will have been weeded out).
> BTW for clarification purposes, pd-l2ork is tested by a couple of core
developers, including myself almost on a daily basis, plus 12+ members who
have little or no experience with Linux, let alone with PD through the
laptop orchestra, and finally a bunch of kids through various k12 education
initiatives (who also have little or no knowledge of Linux or PD). I feel
that is fairly sufficient for my needs.
> Also, to clarify another point that has been brought up several times on
this mailing list, while pd-l2ork does not support Windows or Mac at this
time, this is mainly due to lack of human resources, rather than some kind
of religious mission. There is clearly an intent on supporting those once
we complete port to Qt toolkit. Until then, there is a bootable USB stick
that boots on most computers, and has its own environment, including a
persistent home directory. There are exceptions-- select laptops that
stubbornly lock down their EFI making them not fully compliant with
boota

Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)

[Ivica Bukvic]

On Dec 22, 2014 10:23 PM, "Dan Wilcox"  wrote:
>
>
>> On Dec 22, 2014, at 2:55 AM, Jonathan Wilkes  wrote:
>>
>> Unless you want an enormous number of patches in the wild to bit-rot,
you're going to have a "Install Pd-extended libraries" button.  If you have
that button, then presumably at least _one_ person is going to need to
build and test the whole enchilada, no?
>
>
> I disagree. If it’s easier to build, then it will be easier for a number
of people to test on their respective OS. I assume l2ork doesn’t rely on
one person testing and building across multiple platforms? I’ve been in
that situation already and it sucks. Much nicer to split up the work,
better still if the makefiles work and we have some scripting to handling
automation, fetching, etc for developers and volunteer testers.

Actually, you're simply trading one shortcoming for another, and I would
argue you're shortcoming is a lot harder to troubleshoot. If you provide a
monolithic distribution to all of your users, then reproducing their
problems becomes exponentially easier as opposed to encouraging each user
to install select externals which may clash with each other in unusual ways
that may not be apparent otherwise and then trying to backtrace and
troubleshoot their specific set up as opposed to relying on one monolithic
release that you can easily reproduce on your own computer. If we had
infinite time on this rock this may be a feasible option. As for me,
particularly considering I am doing this not because I am getting paid to
do it, monolithic approach is the way to go with the ultimate goal of
having all externals in the extra folder and without any subfolders (in
part because duplicates and buggy externals will have been weeded out).

BTW for clarification purposes, pd-l2ork is tested by a couple of core
developers, including myself almost on a daily basis, plus 12+ members who
have little or no experience with Linux, let alone with PD through the
laptop orchestra, and finally a bunch of kids through various k12 education
initiatives (who also have little or no knowledge of Linux or PD). I feel
that is fairly sufficient for my needs.

Also, to clarify another point that has been brought up several times on
this mailing list, while pd-l2ork does not support Windows or Mac at this
time, this is mainly due to lack of human resources, rather than some kind
of religious mission. There is clearly an intent on supporting those once
we complete port to Qt toolkit. Until then, there is a bootable USB stick
that boots on most computers, and has its own environment, including a
persistent home directory. There are exceptions-- select laptops that
stubbornly lock down their EFI making them not fully compliant with
bootable USB stick format. Examples of this that I observed include select
Apple hardware (as part of their ongoing "we know better than the user"
walled garden initiative) and a few Dell and Alienware machines (in other
words, select companies in close relationships with Microsoft).

>
>> Btw-- are there poisonous spiders lurking in the Pd-extended makefiles?
Just reading this thread and seeing alternatives like "let's just port apt
to some proprietary OSes" seems odd to me…
>
>
> I agree. I, for one, say let’s make sure the makefiles work well before
getting into package management (if at all).
>
>> So I guess I'll add my own idea to this mix: how about replacing every
single external binary with an abstraction?  Then the external libs become
portable without having to compile a single thing.  Plus any Pd user
willing to click the object can potentially fix bugs or make improvements.
Sure, you can't do Gem and some of the fancy stuff, but those are details.
This would also increase the incentives for doing development to the core
which makes abstractions faster.
>
>
> rjlib, etc have done some of this already and I’ve followed when I
started reimplementing my abstraction library. Honestly, I don’t think this
community has the resources to tackle an effort like that, regardless of
the technical issues that would need to be fixed. I think it’s far more
pragmatic to work on making it easier to split up the maintenance work on
the existing externals and allow for more people to hep testing, building,
and using them outside of a monolithic Pd-extended release. Again, this
approach has worked for other projects like OpenFrameworks, so I think it
can be applicable to Pd. This way, also, we still allow for the freedom of
the users to step up and dictate which externals they want to keep using
without throwing out all the work and useful source code that already
exists.
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
htt

Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)

[Ivica Bukvic]

On Dec 20, 2014 2:05 PM, "Alexandre Torres Porres"  wrote:
>
> cool, so I supose we could share this cleanup process... right?
>
> I see a lot here about pd-l2ork, I've never used it cause I'm not on
Linux but it looks like it could be an alternative to extended if it could
also run in windows/mac OS. I'm assuming this has been asked/discussed
before over here, but I'll shoot again: any plans for that happening?

Short answer is yes. It is probably usable as-is ( there may be a few
things to check TCL-side plus updating the autobuild script). I just never
bothered building it. Help on this front is most welcome. As far as my
priority list is concerned, I would like to finish qt port before delving
into OSX and Windows support because once that is complete, supporting
consistent GUI on all three platforms will become near seamless.

Best,

Ico

>
> cheers
>
> 2014-12-20 8:28 GMT-02:00 Ivica Bukvic :
>
>> FWIW, a good chunk of this cleanup is currently taking place in
pd-l2ork. Namely, we are looking for redundant objects which are then
disabled and replaced by legacy abstractions where possible or linked to
other objects with identical or near identical functionality (again, where
possible); we are disabling problematic objects that have design issues
(e.g. foxy and flatspace IIRC), as well as looking to replace those with
new objects that provide said functionality the right way. Finally, we are
looking to standardize documentation (e.g. pd-l2ork has documentation for
the entire cyclone adapted to the pddp format). If anyone desires git
access to assist with this, please let us know.
>>
>> Please note that in this process the primary goal/mission/mantra is to
create a clean and consistent environment for new users which may also mean
that some of us weathered PD users may have to adapt our old patches
because certain objects may not be available anymore.
>>
>> Best,
>>
>> Ico
>>
>> On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres" 
wrote:
>>>
>>> Yep Alessio. It's time to mean business. So I volunteer
>>>
>>> 1. Identify which externals to include in the repo (for linux users,
the folder /usr/lib/pd-extended/extra can be a good starting point)
>>>
>>> The Pd extended libraries is a good starting point for all OS users, I
guess. Not that I love all that there is there. IMHO there's a lot of junk.
Even in the libraries I've mentioned I can't live without and are
considered to be more stable I see some issues. Most of all, I'm usually
unhappy about some help files that are quite crappy (like incomplete,
sometimes the help files don't even work and you have to tweak them to hear
something).
>>>
>>> Other stuff I see, for example... just yesterday I learned about a new
object for me, [LFO_noise~], and it's not working properly (it's frequency
is twice than it should be). Other than that, it is redundanct, there are
also two other objects that do exactly the same: [rand~] from cyclone and
[noisi~] from zexy. I'd say just throw this "extra not working properly one
away".
>>>
>>> So I can volunteer to manage some of these libraries and rewrite the
help files so that they are also vanilla compatible (that is, they don't
call objects from other libraries, other than the ones from the same
library).
>>>
>>> I can't code! And I've compiled anything only a couple of times in my
life. So I can't really help much with coding, and that's why I'd rather
throw something away that doesn't properly work and has alternatives from
other libraries. But I don't oppose if someone wants to fix stuff. I
remember it wasn't exactly rock science to compile libraries, so I guess I
can try and do it for the latest MAC OS systems on intel machines.
>>>
>>> cheers
>>>
>>> 2014-12-19 9:51 GMT-02:00 Alessio Degani :
>>>>
>>>> At this point I think that we can start to talk about technical stuff
like roadmap, tasks, volunteers recruitment and so on :)
>>>>
>>>> The basic steps, IMHO, can be:
>>>> 1. Identify which externals to include in the repo (for linux users,
the folder /usr/lib/pd-extended/extra can be a good starting point)
>>>> 2. Identify which externals need to be compiled (some of them, as far
as I rememer, are not "true" external library, but a pd patch
[intrinsically cross-platform??])
>>>> 3. Identify which externals are mainteined/unmaintained, and
eventually, contact the maintainers just to say: "hello, we are creating a
shared repo of externals. Are you interested? and so on..."
>>>> 4. Prioritize (i.e. most used extensions have the priority).
>

Re: [PD] [Bulk] Re: [Bulk] Extending Vanilla (was Cyclone help patches & issue list)

[Ivica Bukvic]

FWIW, a good chunk of this cleanup is currently taking place in pd-l2ork.
Namely, we are looking for redundant objects which are then disabled and
replaced by legacy abstractions where possible or linked to other objects
with identical or near identical functionality (again, where possible); we
are disabling problematic objects that have design issues (e.g. foxy and
flatspace IIRC), as well as looking to replace those with new objects that
provide said functionality the right way. Finally, we are looking to
standardize documentation (e.g. pd-l2ork has documentation for the entire
cyclone adapted to the pddp format). If anyone desires git access to assist
with this, please let us know.

Please note that in this process the primary goal/mission/mantra is to
create a clean and consistent environment for new users which may also mean
that some of us weathered PD users may have to adapt our old patches
because certain objects may not be available anymore.

Best,

Ico
On Dec 19, 2014 1:49 PM, "Alexandre Torres Porres"  wrote:

> Yep Alessio. It's time to mean business. So I volunteer
>
> *1. Identify which externals to include in the repo (for linux users, the
> folder /usr/lib/pd-extended/extra can be a good starting point)*
>
> The Pd extended libraries is a good starting point for all OS users, I
> guess. Not that I love all that there is there. IMHO there's a lot of junk.
> Even in the libraries I've mentioned I can't live without and are
> considered to be more stable I see some issues. Most of all, I'm usually
> unhappy about some help files that are quite crappy (like incomplete,
> sometimes the help files don't even work and you have to tweak them to hear
> something).
>
> Other stuff I see, for example... just yesterday I learned about a new
> object for me, [LFO_noise~], and it's not working properly (it's frequency
> is twice than it should be). Other than that, it is redundanct, there are
> also two other objects that do exactly the same: [rand~] from cyclone and
> [noisi~] from zexy. I'd say just throw this "extra not working properly one
> away".
>
> So I can volunteer to manage some of these libraries and rewrite the help
> files so that they are also vanilla compatible (that is, they don't call
> objects from other libraries, other than the ones from the same library).
>
> I can't code! And I've compiled anything only a couple of times in my
> life. So I can't really help much with coding, and that's why I'd rather
> throw something away that doesn't properly work and has alternatives from
> other libraries. But I don't oppose if someone wants to fix stuff. I
> remember it wasn't exactly rock science to compile libraries, so I guess I
> can try and do it for the latest MAC OS systems on intel machines.
>
> cheers
>
> 2014-12-19 9:51 GMT-02:00 Alessio Degani :
>
>>  At this point I think that we can start to talk about technical stuff
>> like roadmap, tasks, volunteers recruitment and so on :)
>>
>> The basic steps, IMHO, can be:
>> 1. Identify which externals to include in the repo (for linux users, the
>> folder /usr/lib/pd-extended/extra can be a good starting point)
>> 2. Identify which externals need to be compiled (some of them, as far as
>> I rememer, are not "true" external library, but a pd patch [intrinsically
>> cross-platform??])
>> 3. Identify which externals are mainteined/unmaintained, and eventually,
>> contact the maintainers just to say: "hello, we are creating a shared repo
>> of externals. Are you interested? and so on..."
>> 4. Prioritize (i.e. most used extensions have the priority).
>> 5. Assign tasks
>>
>> In that context, a web platform can help to accomplish this preliminary
>> steps. For example github (that has a project wiki), or Azendoo (free -and
>> simple!- collaborative project management), to name a few. I'm not an
>> expert of this platform, but I use github for small projects and IMHO,
>> Azendoo (or something like that) it can help a lot for discussions, task
>> management and so on, without flooding the mailing list :)
>>
>> Here is just my thoughts... any idea/suggestion/alternative are
>> appreciated! :)
>>
>> Cheers
>>
>> Alessio
>>
>>
>> On 18/12/2014 20:50, Alexandre Torres Porres wrote:
>>
>> Well, for starters, there could just be a repository with externals and
>> libraries :)
>>
>>  I'm willing to help somehow. I'm not a programmer only, but I can help
>> organising it and stuff. Testing libraries, listing it, etc.
>>
>>  Cheers
>>
>> 2014-12-18 17:34 GMT-02:00 IOhannes m zmölnig :
>>>
>>> On 12/18/2014 08:16 PM, Samuel Burt wrote:
>>> > 1. Opening a patch with [import cyclone] would automatically download
>>> the
>>>
>>> i *strongly* oppose to anything that automatically connects to the
>>> internet and fetches or submits data.
>>>
>>> mgfdsr
>>> IOhannes
>>>
>>>
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> http://lists.puredata.info/listinfo/pd-list
>>>
>>>
>>

Re: [PD] Cyclone help patches & issue list

[Ivica Bukvic]

On Dec 13, 2014 8:35 AM, "Fred Jan Kraan"  wrote:
>
> Hi Alexandre,
>
> Thanks for the clarification, I changed the overview. But this is a good
> example for the type of problem that maybe shouldn't be fixed in the
> current objects. How many now working patches will break when the object
> behaviour changes? A workaround could be to create new objects, e.g.
> cartopol2~ and poltocart2~ with the correct behaviour. A correct working
> cartopol~ and poltocart~ would then have to wait for a new library.

FWIW, I adamantly oppose this kind of an approach within pd-l2ork because
if the original object behaves wrong, it needs to be fixed. And if any
patches really on this wrong behavior they should be fixed as well.
Otherwise, this is not a Max compatibility library and the pd libraries
that are treated this way will morph into a confusing pile of similar
objects with minimal differences and an incredibly steep learning curve.

>
> Some community input is welcome on this.
>
> The plan now is to further investigate the items on the list, create
> bug-report tickets at https://sourceforge.net/p/pure-data/bugs, try to
> fix the problem, test it and create and insert code-patches at
> https://sourceforge.net/p/pure-data/patches/ and then have them apply to
> the code. The mechanism is just for this and it is operational. The list
> on my site should be seen as just a preliminary overview of tasks.
>
> Greetings,
>
> Fred Jan
>
>
> > awesome, though I wouldn't point th issue with cartopol~/poltocar~ as
> > "accuracy", it's just positive when it should be negative and vice
> > versa, but I assume you know what's going on.
> >
> > cheers
> >
> > 2014-12-12 13:03 GMT-02:00 Jonathan Wilkes via Pd-list
> > mailto:pd-list@lists.iem.at>>:
> >
> > Great work!
> >
> > I'll take a look at them for Pd-l2ork.
> >
> > -Jonathan
> >
> >
> > On Friday, December 12, 2014 8:20 AM, Fred Jan Kraan
> > mailto:fjkr...@xs4all.nl>> wrote:
> >
> >
> > Hi all,
> >
> > The set of updated help-patches for the cyclone library is now
complete.
> > I'll check them at least once more time. For now they are at:
> > http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/help-patches
> >
> > Meanwhile there is also a list of issues to fix:
> >
http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
> >
> > If more people want to help, I could put the list in the wiki if I
> > manage to figure out how.
> >
> > Fred Jan
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at  mailing list
> > UNSUBSCRIBE and account-management ->
> > http://lists.puredata.info/listinfo/pd-list
> >
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] passing $0 from an abstraction to another abstraction

[Ivica Bukvic]

FWIW pd-l2ork loadbangs all newly created abstractions.
On Dec 9, 2014 6:06 PM, "i go bananas"  wrote:

> Loadbang doesn't trigger when you create abstractions dynamically.
>
> Use [initbang], or send a message after creating the abstraction to
> trigger the loadbang.  (Look up pd-msg in the help docs)
>
> On Wednesday, December 10, 2014, Alexandros Drymonitis 
> wrote:
>
>> I'm creating an abstraction (say it's called test-parent.pd) which
>> creates another abstraction (called test-child.pd) inside a subpatch, a
>> number of times according to the argument passed to test-parent.pd.
>> What I want to do is store $0 of test-parent.pd and pass it to all
>> instances of test-child.pd to set a name for [throw~] which is in the
>> test-child abstraction, like this (this is in test-parent.pd):
>>
>> [loop] <- this is an until loop with a counter
>> |
>> [t   fb]
>> | |
>> [* 20] [$0]
>> | |
>> | |
>> [pack f f]
>> |
>> [obj 100 $1 test-child $2(
>> |
>> [s subpatch]
>>
>> Inside test-child.pd I have this:
>>
>> [loadbang]
>> |
>> [$1 ]
>> |
>> [set $1-sum(
>> |
>> [throw~]
>>
>> Say that $0 of test parent is 1004. What happens is that, even though all
>> test-child.pd abstractions are created like this [test-child 1004], I get
>> the following error: throw~ 1127-sum: no matching catch
>> There is a [catch~ $0-sum] in test-parent.pd, which, I guess, is updated
>> accoridng to $0, but [test-child] seems to have been stuck to 1127 (I'm
>> clearing the subpatch where all [test-child]s are being created, and then
>> create the abstractions)...
>> Any clues?
>>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Cyclone suite initiative

[Ivica Bukvic]

Why not simply use cyclone help patches provided in pd-l2ork that already
conform to the pddp standard?
On Dec 5, 2014 3:59 PM, "Fred Jan Kraan"  wrote:

> Hi everyone,
>
> Recently I started on improving the help-patches of the cyclone library.
> The idea is to convert then all to the format used by the pd-core
> objects in pd-vanilla, which is also the standard with Pd-l2ork and try
> to improve them a bit on the way.
>
> It is part of a larger initiative to fix the remaining problems with the
> cyclone suite and improve it on newer platforms, including 64-bit
> systems and ARM-architectures.
>
> Awaiting permission to submit the changes into the SVN-repository (hint,
> hint, ...), I collect the help-patches on this page:
> http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/index.html.
> (Already at 30+ of 150+, so ~20% :-) ).
>
> Remarks on these patches or on cyclone objects in general are welcome.
>
> Fred Jan
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] libpd for l2ork?

[Ivica Bukvic]

FWIW, there is every intent on providing libpd-l2ork, eventually. As Dan
pointed out, it is all a matter of adequate manpower. Pd-l2ork has been
already tested extensively as a headless system, which is essentially one
step away from a library. For example, the Cloud installation I premiered
this fall in collaboration with my colleague Aki Ishida had 50 Raspberry
Pis programmed by community participants through a series of 75-minute
workshops using a custom version of pd-l2ork (170+ participants total ages
~6-70+, most if not all who have never seen or used pd and many of whom
have never used any programming language). Afterwards, the installation ran
uninterrupted for over a month without a single RPi ever crashing or
misbehaving in any way.

Best,

Ico
On Nov 13, 2014 10:33 AM, "Dan Wilcox"  wrote:

> Current status is "doesn't exist" as far as I know.
>
> Technically it's possible.
>
> It simply involves bringing in the sources and modifying the make files.
> The wrapper aspect of libpd is separate from the actual pd sources but
> relies on a few changes made under the hood. I believe l2ork is
> sufficiently up to date as compared to vanilla to have most of those.
>
> Practically, it's not possible unless there are more people wanting to
> step up and work on it, specifically on a l2ork version. So far we've
> decided to maintain pd-vanilla compatibility for a lot of reasons, mainly
> that this is where libpd started. Time wise, we've take small steps to
> maintain compatibility and performance and, so far, it's worked.
>
> Also, I might be conservative in my patching when using libpd, but there
> hasn't really been a case where I needed any extra functionality that I
> didn't have using rjlib etc. Libpd's intent is not to provide the kitchen
> sink since that's what you can farm out to your GUI layer or framework. The
> main aspect is audio DSP within apps. As it stands now, you can't
> reimplement a *pacthing GUI* with it since you don't have a way to access
> the object graph etc but it defintiely works great as a white box for
> sending samples & control messages in and out.
>
> I basically think of libpd as a pd abstraction running inside an app, not
> "Pure Data" the application running inside an app.
>
>
>> in relation to Pd-l2ork,
>>
>> guys, what's the status of having a 'libpd' for l2ork???  is that
>> possible?
>>
>> sorry for going off topic...but it is something i have wanted to ask for
>> ages.
>>
>>
> --
> Dan Wilcox
> danomatika.com
> robotcowboy.com
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] data structures......

[Ivica Bukvic]

I stand corrected. Apologies for the noise.
On Nov 12, 2014 12:19 PM, "Jonathan Wilkes via Pd-list" 
wrote:

> Well, Miller has recently added the "text" field to [struct], so he does
> work on them, too.
>
> -Jonathan
>
>
>   On Wednesday, November 12, 2014 11:59 AM, Jonathan Wilkes <
> jancs...@yahoo.com> wrote:
>
>
> Pd-l2ork has two internal objects for state-saving called [preset_hub] and
> [preset_node].  I haven't used them a ton but they seem to handle
> abstractions and locality gracefully (even without the need for $0).
>
> As far as data structures, my changes hopefully make them easier to use.
> You can create scalars in object boxes. You can update their appearance by
> sending messages to [draw].  If you just want a single scalar to visualize
> something, you can essentially treat it as a kind of simplified 2d Gem.  In
> that case you don't even have to understand about or even use gpointers.
>
> -Jonathan
>
>
>   On Wednesday, November 12, 2014 9:36 AM, i go bananas <
> hard@gmail.com> wrote:
>
>
> something i have thought for a LONG time, and i guess a few others have
> too.
>
> They are just too hard to use.
>
> but they keep popping up in updates to pd, so it seems they are still
> being worked on.
>
> couldn't that work be put to better use?
>
> like, for instance, on a native PD state saving system???
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] ANN: SEAMUS 2015 -- Call for submissions

[Ivica Bukvic]

Apologies for x-posting:

The SEAMUS 2015 conference will be held at Virginia Tech during March
26-28, 2015. The conference theme is "Emotion and Electroacoustic Music."
The submission deadline is October 31, 2014. Please see http://
seamus.music.vt.edu
/main/ 
for further details on the conference, and http://
www.seamusonline.org/
 for further information about SEAMUS.

Any questions regarding the conference may be directed to seamus@
music.vt.edu .

Best,

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

Re: [PD] "list foreach"?

[Ivica Bukvic]

Oh dear...

On Oct 9, 2014 11:31 PM, "Chris McCormick"  wrote:
>
> On 09/10/14 22:51, Ivica Ico Bukvic wrote:
> > ... One could argue that those using a pd-fork would benefit, and
> > just maybe if vanilla contributors felt compelled to do so, they could
> > also borrow code and implement it in their version as well?
>
> I'm confused, is this a pull request?

Not at all. Merely a correction of verbiage suggesting that an
implementation of a desired feature in a fork is worthless.

>
> In my experience the most effective way to get code merged into an open
> source project is as follows:
>
>  * Make a small, clean, self contained patch that changes as little of
> the codebase as possible to accomplish a goal.

Check.

>
>  * Format your code to match the style of the codebase it is going in to.
>

Check.

>  * Advocate for the patch directly with the maintainer and on the
> mailing list. In the past "lots of people have requested this feature"
> has worked for me as a lobbying point.

Houston, we got problem. I did this before I forked. And when I have to
spend 4x time advocating something than what it took me to build it (even
when building it was time consuming ordeal in and of itself), and then
still not get it merged, I am sorry but life is too short for such
pointless banter. I will much rather code instead and produce 4 more
patches. Worse yet, many of the proposed fixes afterwards never actually
got fixed in any of the possible alternative ways...

>
>  * If changes are suggested by the maintainer, address them and resubmit.

What if suggestions make no sense or are so off-topic that it is pointless
or incredibly time consuming to even discuss them? Or better yet, there is
no response and your work depends on those changes being in the code?

>
>  * Accept that some patches simply won't go in. In that case you are of
> course welcome to fork, or to maintain the patch in a parallel branch.

I did, and hence the fork.

>
>  * Don't be a dick. I'm happy to note that the era of Pd-powered
> missiles seems to be over. Good riddance!

Seriously? So, by suggesting that a fork user patching a fork of their
preference is not worthless, as suggested by Frank, in part also because it
may trickle back into upstream is being a dick? Or were you referring to
Frank's remark?

>
> Here is someone smarter than me writing in more depth on this subject:
>
>
http://people.redhat.com/rjones/how-to-supply-code-to-open-source-projects/#patches

Might I suggest reading up on history of my contributions before playing a
jump-to-conclusions game? That may help you imply less and understand more.

>
> Of course, Pd-l2ork is a fork and you are obviously welcome to do
> whatever you want. What I don't think is constructive is implying that

What I don't think is constructive is implying what you think I was
implying.

> Miller should be traipsing through the Pd-l2ork codebase and cherry
> picking stuff he likes out and doing the work to merge those changes
> cleanly into Pd. Just think about how you'd react if someone forked
> Pd-l2ork, made monolithic changes to the codebase, and then asked you to
> go through it and find stuff you might like to merge back into Pd-l2ork.

I never suggested that anyone should browse my code. And even in the case
someone did, there is this thing called git, and pd-l2ork's typically
contains patches that are for the most part manageable. And as I have done
before on this list I typically pointed out a link to the relevant fix.
Now, as code base diverges more and more over time such fixes will continue
to make less and less sense, but that is a completely different matter...

BTW, Miller did mention last time we spoke that he would like to
borrow/rewrite preset and undo mechanisms, but this would be a mega patch
to begin with, and I have no interest in providing such a patch knowing how
unlikely it is for it to be merged. So, you have a choice, stick with
whatever makes your life easier, and then accept the limitations of your
choice.

As for your question, I don't care if you or anyone else forks pd-l2ork.
It's been already done and re-merged many times. I also would not call
anyone a dick or their contribution worthless for merely suggesting that
they may have a patch to offer upstream that I could review at my own
discretion and choose to merge or not, and particularly if I did not know
much about the history of said choices...

>
> Traditionally in open source projects that isn't the way that software
> gets patched. Traditionally, a community of developers tries to submit
> patches to a maintainer and lobbies for their acceptance. We are all
> very busy and that seems to be the most effective way to get code merged.

Might I suggest that you read up on history before trying to preach how the
open source development is done?

>
> Let me re-iterate again that you have every right not to do this, and
> your fork is an amazing piece of work, and I wish you good luck and much
> genuine respect for 

Re: [PD] Audio properties dialog

[Ivica Bukvic]

ALSA appears to have it but I notice no observable changes in perceived
latency.
On Oct 7, 2014 6:54 PM, "Miller Puckette"  wrote:

> I couldn't immediately find anything short of going through each
> s_audio_*.c
> implementation and checking whether the "blocksize" parameter in the open
> routine gets used... ugh.
>
> M
>
> On Tue, Oct 07, 2014 at 09:14:43PM +, Jonathan Wilkes via Pd-list
> wrote:
> > Thanks.
> > Is there a quick way to figure out which APIs use it?
> > -Jonathan
> >
> >
> >  On Tuesday, October 7, 2014 5:07 PM, Miller Puckette 
> wrote:
> >
> >
> >  Sorry - I had forgotten an important detail - not every API implements
> > blocksize.  In cases where either you can't or it would never help
> anything,
> > it's simply left at 64.  (and really, the control shouldn't appear on the
> > dialog when it isn't used :)
> >
> > I believe blocksize is most important in windows.
> >
> > cheers
> > Miller
> >
> > On Tue, Oct 07, 2014 at 02:15:09PM -0400, Ivica Ico Bukvic wrote:
> > > On 10/07/2014 01:41 PM, Miller Puckette wrote:
> > > >sys_blksize() reports the block size used by Pd's acheduler (I
> believe it's
> > > >always 64 in valnilla but will be settable someday :)
> > > >
> > > >the I/O blocksize, which is set in the audio settings dialog, is what
> > > >Pd uses to interface with whatever audio API is in use.
> > >
> > > Thanks for the clarification, Miller. What I am confused by is that
> when
> > > using ALSA and changing blocksize from 64 to 2048, there is no audible
> > > difference in the delay, even though it should be profound enough to be
> > > preceivable by ear. Is this because ALSA has another internal buffer
> that
> > > essentially supersedes either blocksize, making the final output
> (near?)
> > > identical?
> > >
> > > Also, response to Jonathan's follow-up question regarding JACK would be
> > > appreciated. It seems from looking at the code, JACK does not care
> about
> > > blocksize variable but I could be easily missing something.
> > >
> > > Best,
> > >
> > > Ico
> > >
> > > >
> > > >cheers
> > > >M
> > > >
> > > >On Tue, Oct 07, 2014 at 05:30:55PM +, Jonathan Wilkes via Pd-list
> wrote:
> > > >>Hi list,What does the blocksize entry box in audio dialog
> properties do?  And how does that value relate (if at all) to the value
> output by sys_getblksize?
> > > >>Thanks,Jonathan
> > > >>___
> > > >>Pd-list@lists.iem.at mailing list
> > > >>UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> > > >
> > > >___
> > > >Pd-list@lists.iem.at mailing list
> > > >UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> > >
> > >
> > > --
> > > Ivica Ico Bukvic, D.M.A.
> > > Associate Professor
> > > Computer Music
> > > ICAT Senior Fellow
> > > DISIS, L2Ork
> > > Virginia Tech
> > > School of Performing Arts - 0141
> > > Blacksburg, VA 24061
> > > (540) 231-6139
> > > i...@vt.edu
> > > www.performingarts.vt.edu
> > > disis.music.vt.edu
> > > l2ork.music.vt.edu
> > >
> > >
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> >
> >
>
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Why do i get glitches at 70% cpu load?

[Ivica Bukvic]

FWIW IIRC you should be able to compile freeverb with appropriate
optimization flag where denormals should not affect it.
On Oct 4, 2014 6:46 PM, "James Dunn"  wrote:

> Are you using [freeverb~]?
>
> This can cause excessive CPU usage due to denormals. Try putting the
> [freeverb~] object in a subpatch and [switch~] off audio processing for
> that subpatch or add a small amount of [noise~] to the input.
>
> Quoth Ronni Montoya, on 04/10/2014 21:34:
>
>> Hi, i have a very big patch that is producing glitches at 70% cpu load.
>> Is this normal behaivor?   With my old computer i only used to get
>> glitches when i go over 100 % cpu load .any idea why its producing
>> 70% cpus load?
>> The patch has a lot subpatches and a lot of big tables with data (like
>> 100 tables)  ... is this a bad practice in pd?   having a lot of
>> subpatches, gui elements  and tables can affect the sound?
>> Do you think that it would be better if i put all in just one patch (
>> withouth too much subpatches?), and delete gui elements ? maybe are
>> the tables?
>> What do you recommend me?
>>
>>
>> cheers
>>
>> R.
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>> listinfo/pd-list
>>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] message box <-> text editing?

[Ivica Bukvic]

Miller et al,

You may want to search pd-l2ork source. Pd-l2ork has a fairly comprehensive
support for ctrl+arrows, home, end as well as up/down arrows by themselves.

Best,

Ico
On Sep 28, 2014 12:13 AM, "Miller Puckette"  wrote:

> I can't remember when that disappeared - years ago.
>
> Anyhow, the up and down arrows should do something more intelligent in
> messagee boxes than they do at present...
>
> cheers
> M
>
> On Sat, Sep 27, 2014 at 10:52:20PM -0400, Jaime E Oliver wrote:
> > Hi all,
> >
> > Whatever happened to the feature that let one edit message boxes as if
> with a text editor? I think I used to hit ctl+t in a message box and got a
> text editor-like window where you could move up and down rows and not only
> forward or backward one character at a time as with regular messages. Quite
> useful and haven't found it in a while. do i have the wrong command? or was
> this feature abandoned? (or never released?)
> >
> > best,
> >
> > J
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Updated pd-extended

[Ivica Bukvic]

...As strange as it may sound I must admit I've missed our broken
conversations/banter. Welcome back, Hans!

Alas, this time I will have to bow out--so many things to do, so little
time. Hope you'll understand.

Best,

Ico
On Sep 25, 2014 11:08 AM, "Hans-Christoph Steiner"  wrote:

>
> You can take an external compiled for the same OS/arch and it loads and
> works
> on all of them.
>
> .hc
>
> Ivica Bukvic wrote:
> > Based on what metrics?
> > On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner" 
> wrote:
> >
> >>
> >> For libraries, there is binary compatibility between pd vanilla,
> extended,
> >> desiredata, and vibrez.  desiredata made much larger changes to the
> >> GUI-side
> >> than pd-l2ork.
> >>
> >> .hc
> >>
> >> Ivica Bukvic wrote:
> >>> Why is this such a problem? I did not break source compatibility (well,
> >>> some of it will happen for gui objects as a result of porting gui to
> qt)
> >>> and for every extended release you recompile new binaries anyhow and so
> >>> does pd-l2ork, except that pd-l2ork goes even one step further
> offering a
> >>> monolithic release. Besides, pd is not java and there is no binary
> >>> compatibility across different platforms (except maybe libpd realized
> in
> >>> java, but that is not what we are talking about here). Under such
> >>> circumstances, I see binary compatibility strictly as a means of
> >>> maintaining status quo. As a final thought, consider that a lot of good
> >>> work (as you called it, and I thank you for your kind words) would not
> >> have
> >>> been possible without breaking binary compatibility which, given the
> >>> aforesaid circumstances, is a non-issue to begin with.
> >>>
> >>> Best,
> >>>
> >>> Ico
> >>> On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" 
> >> wrote:
> >>>
> >>>>
> >>>> You've done a lot of good work in pd-l2ork, but you also broke binary
> >>>> compatibility of libraries for no good reason.  You could have
> >> implemented
> >>>> that feature in a way that preserved binary compatibility of
> libraries.
> >>>> You
> >>>> still can, and you should.
> >>>>
> >>>> .hc
> >>>>
> >>>> Ivica Bukvic wrote:
> >>>>> Well, I guess you can call me a "developer," whatever that means--I
> >> don't
> >>>>> care that much about titles. Yet, I would argue that as far as low
> >> level
> >>>>> stuff is concerned in recent years pd-l2ork has certainly pushed the
> >>>>> envelope in terms of core development. Even the feature that has
> earned
> >>>> me
> >>>>> the title in quotations delves so deep into the core that currently
> it
> >>>>> cannot be implemented in either vanilla or extended without
> significant
> >>>>> changes even though it retains full backwards compatibility. I would
> >> also
> >>>>> argue it is essential and offers a slew of features that are
> >> unavailable
> >>>> in
> >>>>> any other implementation of presets.
> >>>>>
> >>>>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
> >>>> initially
> >>>>> a conscious decision to allow for faster development while addressing
> >> the
> >>>>> lack of manpower. But that is about to change once we complete port
> to
> >> Qt
> >>>>> library. We already transitioned to Tkpath quite a while ago which
> >>>> allowed
> >>>>> us to use a full SVG-based canvas, so I have no doubt we will be able
> >> to
> >>>> do
> >>>>> this again. Once this is done, we won't have to circumnavigate
> >> exceptions
> >>>>> Tk library requires in order to be compliant with different platforms
> >>>> and I
> >>>>> would argue in turn that will result in faster development. So, if
> you
> >>>> are
> >>>>> really interested in pushing the development of non-vanilla pd I
> think
> >>>> you
> >>>>> should heed some of Jonathan's advice and look for ways how community
> >> can
> >>>>> work togeth

Re: [PD] Updated pd-extended

[Ivica Bukvic]

Based on what metrics?
On Sep 25, 2014 11:05 AM, "Hans-Christoph Steiner"  wrote:

>
> For libraries, there is binary compatibility between pd vanilla, extended,
> desiredata, and vibrez.  desiredata made much larger changes to the
> GUI-side
> than pd-l2ork.
>
> .hc
>
> Ivica Bukvic wrote:
> > Why is this such a problem? I did not break source compatibility (well,
> > some of it will happen for gui objects as a result of porting gui to qt)
> > and for every extended release you recompile new binaries anyhow and so
> > does pd-l2ork, except that pd-l2ork goes even one step further offering a
> > monolithic release. Besides, pd is not java and there is no binary
> > compatibility across different platforms (except maybe libpd realized in
> > java, but that is not what we are talking about here). Under such
> > circumstances, I see binary compatibility strictly as a means of
> > maintaining status quo. As a final thought, consider that a lot of good
> > work (as you called it, and I thank you for your kind words) would not
> have
> > been possible without breaking binary compatibility which, given the
> > aforesaid circumstances, is a non-issue to begin with.
> >
> > Best,
> >
> > Ico
> > On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner" 
> wrote:
> >
> >>
> >> You've done a lot of good work in pd-l2ork, but you also broke binary
> >> compatibility of libraries for no good reason.  You could have
> implemented
> >> that feature in a way that preserved binary compatibility of libraries.
> >> You
> >> still can, and you should.
> >>
> >> .hc
> >>
> >> Ivica Bukvic wrote:
> >>> Well, I guess you can call me a "developer," whatever that means--I
> don't
> >>> care that much about titles. Yet, I would argue that as far as low
> level
> >>> stuff is concerned in recent years pd-l2ork has certainly pushed the
> >>> envelope in terms of core development. Even the feature that has earned
> >> me
> >>> the title in quotations delves so deep into the core that currently it
> >>> cannot be implemented in either vanilla or extended without significant
> >>> changes even though it retains full backwards compatibility. I would
> also
> >>> argue it is essential and offers a slew of features that are
> unavailable
> >> in
> >>> any other implementation of presets.
> >>>
> >>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
> >> initially
> >>> a conscious decision to allow for faster development while addressing
> the
> >>> lack of manpower. But that is about to change once we complete port to
> Qt
> >>> library. We already transitioned to Tkpath quite a while ago which
> >> allowed
> >>> us to use a full SVG-based canvas, so I have no doubt we will be able
> to
> >> do
> >>> this again. Once this is done, we won't have to circumnavigate
> exceptions
> >>> Tk library requires in order to be compliant with different platforms
> >> and I
> >>> would argue in turn that will result in faster development. So, if you
> >> are
> >>> really interested in pushing the development of non-vanilla pd I think
> >> you
> >>> should heed some of Jonathan's advice and look for ways how community
> can
> >>> work together in combining the "best of" and engaging developers and
> >>> "developers" alike who have shown dedication to the cause. But before
> >> that
> >>> can be accomplished, the community should consider agreeing on design
> >>> choices. For instance, pd-l2ork came into existence because it focuses
> on
> >>> more nimble development at the expense of potential loss of backwards
> >>> compatibility (even though after 4 years of development the only
> >>> incompatibility we infatuated is correcting buggy positioning of iemgui
> >>> objects, which is cosmetic in nature) because a good chunk of that
> >>> compatibility stems from buggy implementations that stuck around long
> >>> enough that they became a part of the standard (e.g. iemgui's buggy
> >>> positioning of objects that are arbitrarily offset from their x and y
> >>> positions, as reported by the pd script), which is unfortunate.
> >>>
> >>> Best,
> >>>
> >>> Ico
> >>> On Sep 23, 2014 9:21 AM, "Dan

Re: [PD] Updated pd-extended

[Ivica Bukvic]

Why is this such a problem? I did not break source compatibility (well,
some of it will happen for gui objects as a result of porting gui to qt)
and for every extended release you recompile new binaries anyhow and so
does pd-l2ork, except that pd-l2ork goes even one step further offering a
monolithic release. Besides, pd is not java and there is no binary
compatibility across different platforms (except maybe libpd realized in
java, but that is not what we are talking about here). Under such
circumstances, I see binary compatibility strictly as a means of
maintaining status quo. As a final thought, consider that a lot of good
work (as you called it, and I thank you for your kind words) would not have
been possible without breaking binary compatibility which, given the
aforesaid circumstances, is a non-issue to begin with.

Best,

Ico
On Sep 25, 2014 10:54 AM, "Hans-Christoph Steiner"  wrote:

>
> You've done a lot of good work in pd-l2ork, but you also broke binary
> compatibility of libraries for no good reason.  You could have implemented
> that feature in a way that preserved binary compatibility of libraries.
> You
> still can, and you should.
>
> .hc
>
> Ivica Bukvic wrote:
> > Well, I guess you can call me a "developer," whatever that means--I don't
> > care that much about titles. Yet, I would argue that as far as low level
> > stuff is concerned in recent years pd-l2ork has certainly pushed the
> > envelope in terms of core development. Even the feature that has earned
> me
> > the title in quotations delves so deep into the core that currently it
> > cannot be implemented in either vanilla or extended without significant
> > changes even though it retains full backwards compatibility. I would also
> > argue it is essential and offers a slew of features that are unavailable
> in
> > any other implementation of presets.
> >
> > Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
> initially
> > a conscious decision to allow for faster development while addressing the
> > lack of manpower. But that is about to change once we complete port to Qt
> > library. We already transitioned to Tkpath quite a while ago which
> allowed
> > us to use a full SVG-based canvas, so I have no doubt we will be able to
> do
> > this again. Once this is done, we won't have to circumnavigate exceptions
> > Tk library requires in order to be compliant with different platforms
> and I
> > would argue in turn that will result in faster development. So, if you
> are
> > really interested in pushing the development of non-vanilla pd I think
> you
> > should heed some of Jonathan's advice and look for ways how community can
> > work together in combining the "best of" and engaging developers and
> > "developers" alike who have shown dedication to the cause. But before
> that
> > can be accomplished, the community should consider agreeing on design
> > choices. For instance, pd-l2ork came into existence because it focuses on
> > more nimble development at the expense of potential loss of backwards
> > compatibility (even though after 4 years of development the only
> > incompatibility we infatuated is correcting buggy positioning of iemgui
> > objects, which is cosmetic in nature) because a good chunk of that
> > compatibility stems from buggy implementations that stuck around long
> > enough that they became a part of the standard (e.g. iemgui's buggy
> > positioning of objects that are arbitrarily offset from their x and y
> > positions, as reported by the pd script), which is unfortunate.
> >
> > Best,
> >
> > Ico
> > On Sep 23, 2014 9:21 AM, "Dan Wilcox"  wrote:
> >
> >> I disagree. Your example lists what? 2 more developers? I'm talking
> about
> >> "developers" as in people working the C code, build scripts, tcl/tk etc
> aka
> >> people who could, theoretically, help push out a new Pd-extended
> release.
> >> True, we have plenty of people working on externals, but this is a
> problem
> >> for someone who can go deeper.
> >>
> >> I still maintain that the number of low level developers to overall
> users
> >> (non-developers) is relatively low.
> >>
> >> On Sep 23, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
> >>
> >> However, your description of the user/developer ratio doesn't ring true
> to
> >> me.  There's actually a surplus of developers and development energy-- I
> >> count two implementations of presets in the last year or two (in
> Pd-l2ork
> >> and th

Re: [PD] External/Abstraction Repository (was Pd-extended)

[Ivica Bukvic]

For me the list is large enough to have warranted a fork. Here's just one
to get us started: more than one step of undo.
On Sep 23, 2014 10:31 PM, "Max"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> The discussion about the Pd-extended reanimation left one question open:
> What exactly is it, that people miss in vanilla compared to extended?
>
> Is it the inclusion of a whole lot of externals and abstractions in
> one package?
> Debian/Ubuntu/Mint users already have an easy access to all those,
> because many of them have been packaged.
>
> A possible implementation to bring the same convenience to the other
> platforms would be a kind of a repository in Pd itself. A lot of
> softwares do that. Think of: browser add-ons, eclipse packages, atom
> modules, the node.js package manager or Processing.org libraries.
>
> In Pd this may even be a GUI-Plugin that allows for searching in meta
> information added to the Pd externals/abstractions on sourceforge. And
> a click to download and install them.
>
> If you open a patch with an unknown object in it, the plugin could
> offer you to search for it in the repository.
>
> Just an idea.
>
> 0.5ct.
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iEUEARECAAYFAlQiLIIACgkQ3EB7kzgMM6KMHQCeKmbleZyIbhtGmQXu9IxonoTG
> mwIAli0UgiBA22oaZARevQeRPVlyZeI=
> =fovn
> -END PGP SIGNATURE-
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] pd-l2ork website was: Updated pd-extended

[Ivica Bukvic]

Both valid points and I fully agree with you. FWIW, it's kind of hard
maintaining all that and also developing. If only we could get some help on
this, that will help us move the development forward faster ;-)
On Sep 23, 2014 1:28 PM, "Dan Wilcox"  wrote:

> Yeah, sure. I think I meant more that you could utilize the pure-data.info
> site directly for all the pd-l2ork build/install info and download hosting
> and keep the current l2ork site for the ensemble.
>
> Anyway, just an idea :D In any case, pd-L2ork IMO needs a space to it's
> own, especially if you expand to more platforms & build/install info.
>
> My original criticism was more that there isn't a pd-l2ork section, it's
> listed under "Join the L2orkmania" -> "Software".
>
> On Sep 23, 2014, at 1:22 PM, Ivica Bukvic  wrote:
>
> It is already linked from that site.
> On Sep 23, 2014 12:27 PM, "Dan Wilcox"  wrote:
>
>> Maybe the software portal could be a subdomain or integrated on the
>> pure-data.info site along with vanilla & extended.
>>
>> On Sep 23, 2014, at 12:18 PM, Ivica Bukvic  wrote:
>>
>> True. It is trying to be to many things-- an ensemble and a software
>> portal.
>> On Sep 23, 2014 12:04 PM, "Dan Wilcox"  wrote:
>>
>>> Yes, this is great news. I didn't mean to sound pessimistic earlier,
>>> just realistic.
>>>
>>> My 2cents, though is that the l2ork website is hard to navigate :D
>>>
>>> On Sep 23, 2014, at 11:54 AM, Ivica Bukvic  wrote:
>>>
>>> Well, there is a concerted effort on the pd-l2ork side of things. We now
>>> technically have 3 devs contributing code regularly to git and 3 additional
>>> contributors.
>>> On Sep 23, 2014 11:14 AM, "Dan Wilcox"  wrote:
>>>
>>>> I had to bring up semantics because "developer" means alot of different
>>>> things to alot of different people.
>>>>
>>>> Also, I didn't want to bring up vanilla versus non-vanilla, just
>>>> pointing out that the number of people who could help Hans put out a new
>>>> version of extended is rather low. IMO a languishing extended is bad news
>>>> for Pd in general as it's the go to distribution for most people using Pd
>>>> ... but that's probably for another debate. We all work on what's important
>>>> to us, I'm just sad again to see that the priorities don't seem to match up
>>>> with a concerted joint effort, at least as compared to my experience
>>>> working with OpenFrameworks. But of course what's considered a "concerted,
>>>> joint effort" is also up to interpretation :D
>>>>
>>>> Hopefully we'll have a development meet up at some point soon.
>>>>
>>>> I personally feel guilty seeing things like this come up because I have
>>>> the *ability* to do it, but I don't have the time when trying to balance
>>>> life, work, & art. Honestly, this is when I know I'm probably getting in
>>>> too deep ...
>>>>
>>>> This is why I suggested "graduate students". At this point, up keep and
>>>> versioning should be supported by some sort of institution, if possible,
>>>> and by people who could be rotated in and out.
>>>>
>>>> On Sep 23, 2014, at 10:57 AM, Ivica Bukvic  wrote:
>>>>
>>>> Well, I guess you can call me a "developer," whatever that means--I
>>>> don't care that much about titles. Yet, I would argue that as far as low
>>>> level stuff is concerned in recent years pd-l2ork has certainly pushed the
>>>> envelope in terms of core development. Even the feature that has earned me
>>>> the title in quotations delves so deep into the core that currently it
>>>> cannot be implemented in either vanilla or extended without significant
>>>> changes even though it retains full backwards compatibility. I would also
>>>> argue it is essential and offers a slew of features that are unavailable in
>>>> any other implementation of presets.
>>>>
>>>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
>>>> initially a conscious decision to allow for faster development while
>>>> addressing the lack of manpower. But that is about to change once we
>>>> complete port to Qt library. We already transitioned to Tkpath quite a
>>>> while ago which allowed us to use a full SVG-based canvas

Re: [PD] pd-l2ork website was: Updated pd-extended

[Ivica Bukvic]

It is already linked from that site.
On Sep 23, 2014 12:27 PM, "Dan Wilcox"  wrote:

> Maybe the software portal could be a subdomain or integrated on the
> pure-data.info site along with vanilla & extended.
>
> On Sep 23, 2014, at 12:18 PM, Ivica Bukvic  wrote:
>
> True. It is trying to be to many things-- an ensemble and a software
> portal.
> On Sep 23, 2014 12:04 PM, "Dan Wilcox"  wrote:
>
>> Yes, this is great news. I didn't mean to sound pessimistic earlier, just
>> realistic.
>>
>> My 2cents, though is that the l2ork website is hard to navigate :D
>>
>> On Sep 23, 2014, at 11:54 AM, Ivica Bukvic  wrote:
>>
>> Well, there is a concerted effort on the pd-l2ork side of things. We now
>> technically have 3 devs contributing code regularly to git and 3 additional
>> contributors.
>> On Sep 23, 2014 11:14 AM, "Dan Wilcox"  wrote:
>>
>>> I had to bring up semantics because "developer" means alot of different
>>> things to alot of different people.
>>>
>>> Also, I didn't want to bring up vanilla versus non-vanilla, just
>>> pointing out that the number of people who could help Hans put out a new
>>> version of extended is rather low. IMO a languishing extended is bad news
>>> for Pd in general as it's the go to distribution for most people using Pd
>>> ... but that's probably for another debate. We all work on what's important
>>> to us, I'm just sad again to see that the priorities don't seem to match up
>>> with a concerted joint effort, at least as compared to my experience
>>> working with OpenFrameworks. But of course what's considered a "concerted,
>>> joint effort" is also up to interpretation :D
>>>
>>> Hopefully we'll have a development meet up at some point soon.
>>>
>>> I personally feel guilty seeing things like this come up because I have
>>> the *ability* to do it, but I don't have the time when trying to balance
>>> life, work, & art. Honestly, this is when I know I'm probably getting in
>>> too deep ...
>>>
>>> This is why I suggested "graduate students". At this point, up keep and
>>> versioning should be supported by some sort of institution, if possible,
>>> and by people who could be rotated in and out.
>>>
>>> On Sep 23, 2014, at 10:57 AM, Ivica Bukvic  wrote:
>>>
>>> Well, I guess you can call me a "developer," whatever that means--I
>>> don't care that much about titles. Yet, I would argue that as far as low
>>> level stuff is concerned in recent years pd-l2ork has certainly pushed the
>>> envelope in terms of core development. Even the feature that has earned me
>>> the title in quotations delves so deep into the core that currently it
>>> cannot be implemented in either vanilla or extended without significant
>>> changes even though it retains full backwards compatibility. I would also
>>> argue it is essential and offers a slew of features that are unavailable in
>>> any other implementation of presets.
>>>
>>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
>>> initially a conscious decision to allow for faster development while
>>> addressing the lack of manpower. But that is about to change once we
>>> complete port to Qt library. We already transitioned to Tkpath quite a
>>> while ago which allowed us to use a full SVG-based canvas, so I have no
>>> doubt we will be able to do this again. Once this is done, we won't have to
>>> circumnavigate exceptions Tk library requires in order to be compliant with
>>> different platforms and I would argue in turn that will result in faster
>>> development. So, if you are really interested in pushing the development of
>>> non-vanilla pd I think you should heed some of Jonathan's advice and look
>>> for ways how community can work together in combining the "best of" and
>>> engaging developers and "developers" alike who have shown dedication to the
>>> cause. But before that can be accomplished, the community should consider
>>> agreeing on design choices. For instance, pd-l2ork came into existence
>>> because it focuses on more nimble development at the expense of potential
>>> loss of backwards compatibility (even though after 4 years of development
>>> the only incompatibility we infatuated is correcting buggy positioning of
>>> iemgui  objects, which is cosmetic in 

Re: [PD] Updated pd-extended

[Ivica Bukvic]

True. It is trying to be to many things-- an ensemble and a software portal.
On Sep 23, 2014 12:04 PM, "Dan Wilcox"  wrote:

> Yes, this is great news. I didn't mean to sound pessimistic earlier, just
> realistic.
>
> My 2cents, though is that the l2ork website is hard to navigate :D
>
> On Sep 23, 2014, at 11:54 AM, Ivica Bukvic  wrote:
>
> Well, there is a concerted effort on the pd-l2ork side of things. We now
> technically have 3 devs contributing code regularly to git and 3 additional
> contributors.
> On Sep 23, 2014 11:14 AM, "Dan Wilcox"  wrote:
>
>> I had to bring up semantics because "developer" means alot of different
>> things to alot of different people.
>>
>> Also, I didn't want to bring up vanilla versus non-vanilla, just pointing
>> out that the number of people who could help Hans put out a new version of
>> extended is rather low. IMO a languishing extended is bad news for Pd in
>> general as it's the go to distribution for most people using Pd ... but
>> that's probably for another debate. We all work on what's important to us,
>> I'm just sad again to see that the priorities don't seem to match up with a
>> concerted joint effort, at least as compared to my experience working with
>> OpenFrameworks. But of course what's considered a "concerted, joint effort"
>> is also up to interpretation :D
>>
>> Hopefully we'll have a development meet up at some point soon.
>>
>> I personally feel guilty seeing things like this come up because I have
>> the *ability* to do it, but I don't have the time when trying to balance
>> life, work, & art. Honestly, this is when I know I'm probably getting in
>> too deep ...
>>
>> This is why I suggested "graduate students". At this point, up keep and
>> versioning should be supported by some sort of institution, if possible,
>> and by people who could be rotated in and out.
>>
>> On Sep 23, 2014, at 10:57 AM, Ivica Bukvic  wrote:
>>
>> Well, I guess you can call me a "developer," whatever that means--I don't
>> care that much about titles. Yet, I would argue that as far as low level
>> stuff is concerned in recent years pd-l2ork has certainly pushed the
>> envelope in terms of core development. Even the feature that has earned me
>> the title in quotations delves so deep into the core that currently it
>> cannot be implemented in either vanilla or extended without significant
>> changes even though it retains full backwards compatibility. I would also
>> argue it is essential and offers a slew of features that are unavailable in
>> any other implementation of presets.
>>
>> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was
>> initially a conscious decision to allow for faster development while
>> addressing the lack of manpower. But that is about to change once we
>> complete port to Qt library. We already transitioned to Tkpath quite a
>> while ago which allowed us to use a full SVG-based canvas, so I have no
>> doubt we will be able to do this again. Once this is done, we won't have to
>> circumnavigate exceptions Tk library requires in order to be compliant with
>> different platforms and I would argue in turn that will result in faster
>> development. So, if you are really interested in pushing the development of
>> non-vanilla pd I think you should heed some of Jonathan's advice and look
>> for ways how community can work together in combining the "best of" and
>> engaging developers and "developers" alike who have shown dedication to the
>> cause. But before that can be accomplished, the community should consider
>> agreeing on design choices. For instance, pd-l2ork came into existence
>> because it focuses on more nimble development at the expense of potential
>> loss of backwards compatibility (even though after 4 years of development
>> the only incompatibility we infatuated is correcting buggy positioning of
>> iemgui  objects, which is cosmetic in nature) because a good chunk of that
>> compatibility stems from buggy implementations that stuck around long
>> enough that they became a part of the standard (e.g. iemgui's buggy
>> positioning of objects that are arbitrarily offset from their x and y
>> positions, as reported by the pd script), which is unfortunate.
>>
>> Best,
>>
>> Ico
>> On Sep 23, 2014 9:21 AM, "Dan Wilcox"  wrote:
>>
>>> I disagree. Your example lists what? 2 more developers? I'm talking
>>> about "

Re: [PD] Updated pd-extended

[Ivica Bukvic]

Well, there is a concerted effort on the pd-l2ork side of things. We now
technically have 3 devs contributing code regularly to git and 3 additional
contributors.
On Sep 23, 2014 11:14 AM, "Dan Wilcox"  wrote:

> I had to bring up semantics because "developer" means alot of different
> things to alot of different people.
>
> Also, I didn't want to bring up vanilla versus non-vanilla, just pointing
> out that the number of people who could help Hans put out a new version of
> extended is rather low. IMO a languishing extended is bad news for Pd in
> general as it's the go to distribution for most people using Pd ... but
> that's probably for another debate. We all work on what's important to us,
> I'm just sad again to see that the priorities don't seem to match up with a
> concerted joint effort, at least as compared to my experience working with
> OpenFrameworks. But of course what's considered a "concerted, joint effort"
> is also up to interpretation :D
>
> Hopefully we'll have a development meet up at some point soon.
>
> I personally feel guilty seeing things like this come up because I have
> the *ability* to do it, but I don't have the time when trying to balance
> life, work, & art. Honestly, this is when I know I'm probably getting in
> too deep ...
>
> This is why I suggested "graduate students". At this point, up keep and
> versioning should be supported by some sort of institution, if possible,
> and by people who could be rotated in and out.
>
> On Sep 23, 2014, at 10:57 AM, Ivica Bukvic  wrote:
>
> Well, I guess you can call me a "developer," whatever that means--I don't
> care that much about titles. Yet, I would argue that as far as low level
> stuff is concerned in recent years pd-l2ork has certainly pushed the
> envelope in terms of core development. Even the feature that has earned me
> the title in quotations delves so deep into the core that currently it
> cannot be implemented in either vanilla or extended without significant
> changes even though it retains full backwards compatibility. I would also
> argue it is essential and offers a slew of features that are unavailable in
> any other implementation of presets.
>
> Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially
> a conscious decision to allow for faster development while addressing the
> lack of manpower. But that is about to change once we complete port to Qt
> library. We already transitioned to Tkpath quite a while ago which allowed
> us to use a full SVG-based canvas, so I have no doubt we will be able to do
> this again. Once this is done, we won't have to circumnavigate exceptions
> Tk library requires in order to be compliant with different platforms and I
> would argue in turn that will result in faster development. So, if you are
> really interested in pushing the development of non-vanilla pd I think you
> should heed some of Jonathan's advice and look for ways how community can
> work together in combining the "best of" and engaging developers and
> "developers" alike who have shown dedication to the cause. But before that
> can be accomplished, the community should consider agreeing on design
> choices. For instance, pd-l2ork came into existence because it focuses on
> more nimble development at the expense of potential loss of backwards
> compatibility (even though after 4 years of development the only
> incompatibility we infatuated is correcting buggy positioning of iemgui
> objects, which is cosmetic in nature) because a good chunk of that
> compatibility stems from buggy implementations that stuck around long
> enough that they became a part of the standard (e.g. iemgui's buggy
> positioning of objects that are arbitrarily offset from their x and y
> positions, as reported by the pd script), which is unfortunate.
>
> Best,
>
> Ico
> On Sep 23, 2014 9:21 AM, "Dan Wilcox"  wrote:
>
>> I disagree. Your example lists what? 2 more developers? I'm talking about
>> "developers" as in people working the C code, build scripts, tcl/tk etc aka
>> people who could, theoretically, help push out a new Pd-extended release.
>> True, we have plenty of people working on externals, but this is a problem
>> for someone who can go deeper.
>>
>> I still maintain that the number of low level developers to overall users
>> (non-developers) is relatively low.
>>
>> On Sep 23, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
>>
>> However, your description of the user/developer ratio doesn't ring true
>> to me.  There's actually a surplus of developers and 

Re: [PD] Updated pd-extended

[Ivica Bukvic]

Well, I guess you can call me a "developer," whatever that means--I don't
care that much about titles. Yet, I would argue that as far as low level
stuff is concerned in recent years pd-l2ork has certainly pushed the
envelope in terms of core development. Even the feature that has earned me
the title in quotations delves so deep into the core that currently it
cannot be implemented in either vanilla or extended without significant
changes even though it retains full backwards compatibility. I would also
argue it is essential and offers a slew of features that are unavailable in
any other implementation of presets.

Pd-l2ork's greatest deterrent is exclusivity to Linux, which was initially
a conscious decision to allow for faster development while addressing the
lack of manpower. But that is about to change once we complete port to Qt
library. We already transitioned to Tkpath quite a while ago which allowed
us to use a full SVG-based canvas, so I have no doubt we will be able to do
this again. Once this is done, we won't have to circumnavigate exceptions
Tk library requires in order to be compliant with different platforms and I
would argue in turn that will result in faster development. So, if you are
really interested in pushing the development of non-vanilla pd I think you
should heed some of Jonathan's advice and look for ways how community can
work together in combining the "best of" and engaging developers and
"developers" alike who have shown dedication to the cause. But before that
can be accomplished, the community should consider agreeing on design
choices. For instance, pd-l2ork came into existence because it focuses on
more nimble development at the expense of potential loss of backwards
compatibility (even though after 4 years of development the only
incompatibility we infatuated is correcting buggy positioning of iemgui
objects, which is cosmetic in nature) because a good chunk of that
compatibility stems from buggy implementations that stuck around long
enough that they became a part of the standard (e.g. iemgui's buggy
positioning of objects that are arbitrarily offset from their x and y
positions, as reported by the pd script), which is unfortunate.

Best,

Ico
On Sep 23, 2014 9:21 AM, "Dan Wilcox"  wrote:

> I disagree. Your example lists what? 2 more developers? I'm talking about
> "developers" as in people working the C code, build scripts, tcl/tk etc aka
> people who could, theoretically, help push out a new Pd-extended release.
> True, we have plenty of people working on externals, but this is a problem
> for someone who can go deeper.
>
> I still maintain that the number of low level developers to overall users
> (non-developers) is relatively low.
>
> On Sep 23, 2014, at 6:00 AM, pd-list-requ...@lists.iem.at wrote:
>
> However, your description of the user/developer ratio doesn't ring true to
> me.  There's actually a surplus of developers and development energy-- I
> count two implementations of presets in the last year or two (in Pd-l2ork
> and the Chocolate et Coffee lib) which are in addition to however many
> already exist on svn and the Pd forum.
>
>
> 
> Dan Wilcox
> @danomatika
> danomatika.com
> robotcowboy.com
>
>
>
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] Pd-l2ork bug?

[Ivica Bukvic]

Hey Chris!

Hope all is well. Thanks for the bug report. We are currently squashing
lingering bugs for the next release, so this could not be more timely.

I haven't looked at the s-env yet but a if this is an array window, a quick
fix on pd-l2ork side of things until we fix the bug in question is to
enable jump-on-click option (accessible via array properties window) which
allows you to click anywhere on the array window and you will always select
the closest point in the array.

HTH

Best,

Ico
On Sep 16, 2014 6:01 AM, "Chris McCormick"  wrote:

> Hi Ivica, Jonathan,
>
> A user of s-abstractions is reporting the [s-env] object does not
> function correctly in Pd-l2ork:
>
> https://github.com/chr15m/s-abstractions/issues/1#issuecomment-55527952
>
> I tested Pd Vanilla and it still seems to function correctly. Any ideas?
>
> Cheers,
>
> Chris.
>
> --
> http://mccormick.cx/
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list