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

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

[Dan Wilcox]

Actually one of the problems with extended was that it loaded *everything* by 
default, so people aren’t used to specifying required libs. Imagine if 
[declare] or [import] could also specify lib versions ...


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Dec 22, 2015, at 10:05 PM, Alexandre Torres Porres  
> wrote:
> 
>  Now people who used extended will have to install libraries on their own 
> with deken and need to know what's going on. 

___
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

[Alexandre Torres Porres]

seems the thread has forked, hadn't seen this.

2015-12-22 18:52 GMT-02:00 Fred Jan Kraan :

> Sorry for all the confusion I have apparently created.
>

I feel quite responsible, so apologies as well


> It seems that more words just means more misunderstanding. So here I
> attempt another approach:
>

sounds like a nice approach.


> - trust me, I do not want to kill cyclone
>

I trust you


> - cyclone backward compatibility is more important than Max/MSP
> compatibility,
> - it will take some time to find out the best way to have both.
>

 As long as we can think of a way to have both, I don't really have a
problem. So everything sounds cool and my reply should end here.

But it didn't :) sorry, hope adding more words won't degrade the thread.

I don't agree backwards compatibility is more important than Max/MSP
compatibility in cyclone, and feel that the mere such idea hurts the main
purpose of the project. Now, that's just my opinion. I wonder if what you
shared is just an opinion as well, it wasn't clear. If it's just an
opinion, do you value different ones? I respect different opinions, but I'd
have a problem with it if it'd be imposed as truth over other ones. Anyway,
I believe you're just sharing an opinion, and that you're cool with other
opinions, but I'm just being "that guy", who wants things to be cristal
clear as also an approach to avoid misunderstandings.

Now we can start thinking about best way to have both ;)

cheers
___
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)

[Alexandre Torres Porres]

2015-12-23 1:44 GMT-02:00 Dan Wilcox :

> What about versioning? If people *have* to have older compatibility, then
> why can’t they just run an older version of cyclone?
>

We're not really even at a real discussion where people would *have* and
*need* to stay with an older version of cyclone by the way. I'll get to
that...


Newer development can take place on the current version and you can clearly
> note api changes/updates in a CHANGELOG. Say tag cyclone right now as
> version 1.0.0 and all further development is version 2.0.*
>
> This seems to work fine for all sorts of software libraries and deken
> should make it much more possible in pd.
>

Dan, if I fully get you, I agree and had thought about it. I'm just also
open to those who think differently and care a lot about the compatibility
deal, so I'm also suggesting simple solutions for "everyone to be happy".
But if it was up to me...

Some of the discussion here is based on the worries of breaking patches as
if Pd as if Pd users don't have to be savvy on managing versions and
external libraries, as if they'd be tied up whenever a change was made.
It's almost like as if one would have to search all the patches in the
world, and if one that would be affected was found, the case should be
rested, and nothing could be done...

But let's be reasonable, worls is crazy, life is crazy and also a bitch,
crazy stuff happens all of the time in the Pd world (and in the software
world) and we have to manage that. Now people who used extended will have
to install libraries on their own with deken and need to know what's going
on.

I'm thinking about whenever I create [wrap] in Pd-Extended 0.42-5, it shows
the error: *A new incompatible [wrap] object was introduced in Pd 0.42.*
*... you might be able to track this down from the Find menu.*
* For a backwards-compatible version, use [zexy/wrap]*

That's it, a simple warning, and deal with it... change your patches if you
have to. Change your version, read the changelog, read the help file. Just
point the issue and solutions if they actually show up.

The crazy thing is that, objectively, we're not really even at a real issue
where people would *have* and *need* to stay with an older version of
cyclone. The only thing that came up (a change in behaviour in [average~])
is easily fixable and manageable... it's not like the patch would break
beyond reparability, and even if no message is added to the Pd window
(regarding the new functionality of the object nor anything in the help
file), error messages in the console would still point to the problem
(signal outlet connected to control inlet)... there you go, find te error
and just use a snapshot~ to convert to data then.

But, hey, well, cutting to the chase, I back you up on this one...

cheers
___
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)

[Alexandre Torres Porres]

2015-12-22 21:46 GMT-02:00 Miller Puckette :

> when I find that an object isn't terribly well designed (...) I make
> another one, with another name, that does the job better.
>

Sounds great, too bad the darn thing about cyclone is that we need to stick
to deal with cloning the original objects with their names and
stuff. Although I'm being a major advocate of cyclone and its maintenance,
I actually dislike this fact/restriction. For me it's more the fact that it
is a nice, big and handy collection of objects that adds several
functionalities to Pd. The need to be faithful to max is kind of a bummer,
but that's what cloning is...

cheers
___
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)

[Dan Wilcox]

What about versioning? If people *have* to have older compatibility, then why 
can’t they just run an older version of cyclone? Newer development can take 
place on the current version and you can clearly note api changes/updates in a 
CHANGELOG. Say tag cyclone right now as version 1.0.0 and all further 
development is version 2.0.*

This seems to work fine for all sorts of software libraries and deken should 
make it much more possible in pd.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Dec 22, 2015, at 7:06 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Miller Puckette mailto:m...@ucsd.edu>>
> Subject: Re: [PD] consolidate backward- and MaxMSP compatibility in Cyclone 
> (was: Purpose of Cyclone)
> Date: December 22, 2015 at 4:46:29 PM MST
> To: Alexandre Torres Porres mailto:por...@gmail.com>>
> Cc: "pd-list@lists.iem.at " 
> mailto:pd-list@lists.iem.at>>
> 
> 
> If I may make a suggestion - when I find that an object isn't terribly
> well designed (for example my own qlist :) I make another one, with another
> name, that does the job better (text).
> 
> cheers
> Miller
> 
> On Tue, Dec 22, 2015 at 08:51:03PM -0200, Alexandre Torres Porres wrote:
>> Well, newer patches with newer functionalities not working in older
>> versions is how things go anyway, right? Vanilla 0-46 patches don't run in
>> 0.45 and so on... there's no way around that I guess.
>> 
>>> the dual outlet layout with message left and
>>> signal right is rather unusual.
>> 
>> But I think it's also simpler and more straightforward than introducing
>> flags, arguments and all. It might be unusual, but there are already some
>> objects with similar design, I actually thought of that because of
>> [sampstoms~] and [mstosamps~] - it'd be basically the same design.
>> 
>> cheers

___
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 20151219 now available

[Ivica Ico Bukvic]

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

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

[Antonio Roberts]

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
>



-- 

anto...@hellocatfood.com
http://www.hellocatfood.com


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

[Miller Puckette]

If I may make a suggestion - when I find that an object isn't terribly
well designed (for example my own qlist :) I make another one, with another
name, that does the job better (text).

cheers
Miller

On Tue, Dec 22, 2015 at 08:51:03PM -0200, Alexandre Torres Porres wrote:
> Well, newer patches with newer functionalities not working in older
> versions is how things go anyway, right? Vanilla 0-46 patches don't run in
> 0.45 and so on... there's no way around that I guess.
> 
> > the dual outlet layout with message left and
> > signal right is rather unusual.
> 
> But I think it's also simpler and more straightforward than introducing
> flags, arguments and all. It might be unusual, but there are already some
> objects with similar design, I actually thought of that because of
> [sampstoms~] and [mstosamps~] - it'd be basically the same design.
> 
> cheers
> 
> 2015-12-22 19:48 GMT-02:00 katja :
> 
> > On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres
> >  wrote:
> >
> > > If we're discussing [average~], how about my idea of having a second
> > right
> > > signal outlet as default? I think it's an easy and simple solution. Help
> > > file would explain how the left control outlet is for backwards
> > > compatibility. Done.
> >
> > Yes that would be an easy way to incorporate Fred Jan's signal average
> > output into the existing class. But note that both solutions, dual
> > mode and dual outlet, have a similar forward incompatibility effect. A
> > patch that uses the right signal outlet of a new version won't run
> > with an old average~ binary. So the pros and cons of both solutions
> > are comparable, with the small difference that the dual outlet layout
> > with message left and signal right is rather unusual.
> >
> > Katja
> >

> ___
> 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] consolidate backward- and MaxMSP compatibility in Cyclone (was: Purpose of Cyclone)

[Alexandre Torres Porres]

Well, newer patches with newer functionalities not working in older
versions is how things go anyway, right? Vanilla 0-46 patches don't run in
0.45 and so on... there's no way around that I guess.

> the dual outlet layout with message left and
> signal right is rather unusual.

But I think it's also simpler and more straightforward than introducing
flags, arguments and all. It might be unusual, but there are already some
objects with similar design, I actually thought of that because of
[sampstoms~] and [mstosamps~] - it'd be basically the same design.

cheers

2015-12-22 19:48 GMT-02:00 katja :

> On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres
>  wrote:
>
> > If we're discussing [average~], how about my idea of having a second
> right
> > signal outlet as default? I think it's an easy and simple solution. Help
> > file would explain how the left control outlet is for backwards
> > compatibility. Done.
>
> Yes that would be an easy way to incorporate Fred Jan's signal average
> output into the existing class. But note that both solutions, dual
> mode and dual outlet, have a similar forward incompatibility effect. A
> patch that uses the right signal outlet of a new version won't run
> with an old average~ binary. So the pros and cons of both solutions
> are comparable, with the small difference that the dual outlet layout
> with message left and signal right is rather unusual.
>
> Katja
>
___
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)

[katja]

On Tue, Dec 22, 2015 at 9:41 PM, Alexandre Torres Porres
 wrote:

> If we're discussing [average~], how about my idea of having a second right
> signal outlet as default? I think it's an easy and simple solution. Help
> file would explain how the left control outlet is for backwards
> compatibility. Done.

Yes that would be an easy way to incorporate Fred Jan's signal average
output into the existing class. But note that both solutions, dual
mode and dual outlet, have a similar forward incompatibility effect. A
patch that uses the right signal outlet of a new version won't run
with an old average~ binary. So the pros and cons of both solutions
are comparable, with the small difference that the dual outlet layout
with message left and signal right is rather unusual.

Katja

___
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

[Jonathan Wilkes via Pd-list]

Hi Fred Jan,Sounds good to me.
Keep up the good work.
Best,Jonathan
 

On Tuesday, December 22, 2015 3:53 PM, Fred Jan Kraan  
wrote:
 

 Hi All,

Sorry for all the confusion I have apparently created.

It seems that more words just means more misunderstanding.

So here I attempt another approach:
- trust me, I do not want to kill cyclone,
- cyclone backward compatibility is more important than Max/MSP 
compatibility,
- it will take some time to find out the best way to have both.

Greetings,

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] consolidate backward- and MaxMSP compatibility in Cyclone

[Fred Jan Kraan]

Hi All,

Sorry for all the confusion I have apparently created.

It seems that more words just means more misunderstanding.

So here I attempt another approach:
- trust me, I do not want to kill cyclone,
- cyclone backward compatibility is more important than Max/MSP 
compatibility,

- it will take some time to find out the best way to have both.

Greetings,

Fred Jan

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

[Alexandre Torres Porres]

2015-12-22 12:51 GMT-02:00 katja :

> With the recent increased effort of testing, fixing and innovation there's
> an
> opportunity to redefine intentions and ambitions.


Totally agree, I guess we can just keep the idea that it is a library of
clones in a generic approach that doesn't restrict to "4.5", I guess the
mentioning of that version is because it was the current version at the
time, not because it had to remain restrained to it...

So I think the subtitle description should just be

*a library of clones of Max/MSP objects*


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

Sure. Well, that makes it more generic and open to updates.

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

If we're discussing [average~], how about my idea of having a second right
signal outlet as default? I think it's an easy and simple solution. Help
file would explain how the left control outlet is for backwards
compatibility. Done.


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

I'm seeing if I can find collaborators out there.

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


You can see at the description that it had many ambitions indeed. We could
edit the project like saying it was "meant to eventually become part of a
much larger project, aiming at unification and standardization of computer
musician's tools."

I guess we can edit that and rule it out, hehe...

Project description could tell more about current development, that it
started back in the days of max/msp 4.5 and that it is now open to newer
developments to keep up with latest versions of Max and such details.

I also owe this list a document from my research with a "To Do List", it's
not like it'd be a huge thing, and we could also describe more about the
scope of and focus of the project, which is not suppose to turn Pd into
clone of Max, stuff like that.

Help files could tell up to which version an object is and give details of
what it has or not as a clone in comparison to the original.

I could work on that on the help files.

cheers
___
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)

[Alexandre Torres Porres]

2015-12-22 17:58 GMT-02:00 Jonathan Wilkes :

> I find Fred Jan's maintenance reasonable because sticking with current
> behavior means 0% of patches in
> the wild will be negatively affected.  There's the possibility that his
> maintenance hinders Max compatibility for future
> patches, but this isn't something we can quantify.
>

There's a pretty straightforward and concrete example in discussion, so
it's quantifiable and not a matter of possibility. It's not a hunch about
future development, there's already a present issue regarding the
improvement for porting patches between Pd and Max. More than that,
opinions from maintenance have been stated that Max/Msp compatibility is
not supposed to be a concern anymore...

If you have the opposite hunch then do some data mining so that we can have
> a more meaningful discussion.
>

You're basically just trying to share your opinion (over mine, by the way)
that this should be the way to go... I think this is a meaningless
discussion as it is. I have a perfectly good reason to appreciate and hope
for the compatibility to Max/MSP in cyclone (being that its original
purpose) - but in order to make a case against your opinion, you've
provided an insane and unreasonable task...

And this is after me and others have suggested that this not about a
dilema, that we could meet halfway, more than once... this is in fact the
point of this thread, so this seems also like a pointless discussion to be
raised in here.

cheers
___
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)

[Jonathan Wilkes via Pd-list]

I find Fred Jan's maintenance reasonable because sticking with current behavior 
means 0% of patches in 
the wild will be negatively affected.  There's the possibility that his 
maintenance hinders Max compatibility for future 
patches, but this isn't something we can quantify.
We can _estimate_ the impact of changing Cyclone behavior by taking a large 
sample of patches and mining them to see what percentage would be impacting by 
such a change.  (We can also look specifically at how 
the behavior changes, how easy it is to undo, etc.)  But obviously a change 
affects 1/1 patches is different than 
a change that affects 5000/1 patches.
But doing that would take a lot of time and energy.  I'm not willing to do it, 
and I'm not about to tell Fred Jan to 
do that after he's taken on the task of maintaining an abandoned library.  I'm 
also not willing to do it because I 
don't think it will result in any significant improvement for porting patches 
between Pd and Max.  But again, that's 
just a hunch about future development.
If you have the opposite hunch then do some data mining so that we can have a 
more meaningful discussion.  
Otherwise we're just draining Fred Jan's maintenance energies-- overestimating 
the potential damage of him 
leaving some code untouched, and understimating all the other improvements he's 
doing.
-Jonathan
 

On Tuesday, December 22, 2015 12:56 PM, Alexandre Torres Porres 
 wrote:
 

 
2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list :

Hi anyone encouraging backward breakage,
Please make a collection of as many patches as possible, from as many public 
sources as possible.
Then mine this data to get a sense of what percentage of patches would be 
affected 
by changing a Cyclone class' behavior.

Then let's continue with conversation.
If no one is willing to do this, it's a tacit acknowledgement that Fred Jan is 
taking 
the only sensible approach to maintaining Cyclone.

I don't think I get this, or agree. Are you saying that people who wish to 
break backwards compatibility should check if there's any patch out there which 
could be affected, and then if no patch is affected we could change it? That 
might be logical but not very reasonable. 
But anyway, I don't think we should narrow the discussion to this! 
I guess I might be "one" encouraging backward breakage, although I made 
suggestions to not break it and said that the issue in discussion (the average~ 
object) did not really pose this dilema - let me stress and emphasize that I 
don't believe this is a "A" or "B" choice, and I hope we do not really have to 
discuss this like that.
Katja made other suggestions on how to "meet in the middle", it is perfectly 
possible to change the behaviour with an argument or a message, I agree. No one 
here is just up for backwards compatibility breakage so let's not, please, make 
this such a discussion...
What really concerns me is anyone encouraging the breakage of the purpose of 
cyclone (compatibility to MaxMSP). I don't think this is sensible at all, it is 
a major change of course in the project.
Again, we're not really facing a dilema between backwards compatibility versus 
Max/MSP compatibility, but considering Max/MSP compatibility not a priority 
(even acknowledging there's a mistake that shouldn't be there in the first 
place) kills the main purpose of cyclone and that'ss serious. I'd say it even 
points to a fork in the project. If such a detour in purpose emerges from the 
maintenance, maybe we shouldn't call it "cyclone" anymore.
On te other hand, if one is encouraging Max/Msp compatibility breakage, maybe 
this person could check first if any user will be affected by that change. 
There's me right here, by the way :)
cheers

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

Re: [PD] JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument) JACKerror: JackClient::AcquireSelfRealTime error

[Jonghyun Kim]

unchecked **Realtime** option in QjackCtl Setting Tab. No more error msg...


On Wed, Dec 23, 2015 at 2:22 AM, Jonghyun Kim  wrote:

> added this lines to the end of /etc/security/limits.conf
>
> ===
> @audio   –  rtprio 99
> @audio   –  memlockunlimited
> @audio   –  nice  -10
> ===
> sudo usermod -a -G audio MY_USER_ID
>
>
> On Wed, Dec 23, 2015 at 2:01 AM, Jonghyun Kim 
> wrote:
>
>> however, no sound problem, no bad messages on qjackctl.
>>
>> On Wed, Dec 23, 2015 at 1:54 AM, Jonghyun Kim 
>> wrote:
>>
>>> hi list,
>>>
>>> JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument)
>>> JACKerror: JackClient::AcquireSelfRealTime error
>>>
>>> this errors occurs every pd variants on my system: pd-vanliia 0.46-7,
>>> 0.45-4, pd-extended 0.43-4, but no errors with pd-l2ork 20151219(based on
>>> pd 0.42? i guess?).
>>>
>>> my system:
>>> ubuntu 14.04-3 LTS 64 bit
>>> jackdmp 1.9.10
>>> qjackctl 0.3.10
>>>
>>> thanks,
>>> jonghyun kim
>>>
>>
>>
>
___
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)

[Alexandre Torres Porres]

2015-12-22 15:25 GMT-02:00 Jonathan Wilkes via Pd-list :

> Hi anyone encouraging backward breakage,
> Please make a collection of as many patches as possible, from as many
> public
> sources as possible.
>
> Then mine this data to get a sense of what percentage of patches would be
> affected
> by changing a Cyclone class' behavior.
>
> Then let's continue with conversation.
>
> If no one is willing to do this, it's a tacit acknowledgement that Fred
> Jan is taking
> the only sensible approach to maintaining Cyclone.
>

I don't think I get this, or agree. Are you saying that people who wish to
break backwards compatibility should check if there's any patch out there
which could be affected, and then if no patch is affected we could change
it? That might be logical but not very reasonable.

But anyway, I don't think we should narrow the discussion to this!

I guess I might be "one" encouraging backward breakage, although I made
suggestions to not break it and said that the issue in discussion (the
average~ object) did not really pose this dilema - let me stress and
emphasize that I don't believe this is a "A" or "B" choice, and I hope we
do not really have to discuss this like that.

Katja made other suggestions on how to "meet in the middle", it is
perfectly possible to change the behaviour with an argument or a message, I
agree. No one here is just up for backwards compatibility breakage so let's
not, please, make this such a discussion...

What really concerns me is anyone encouraging the breakage of the purpose
of cyclone (compatibility to MaxMSP). I don't think this is sensible at
all, it is a major change of course in the project.

Again, we're not really facing a dilema between backwards compatibility
versus Max/MSP compatibility, but considering Max/MSP compatibility not a
priority (even acknowledging there's a mistake that shouldn't be there in
the first place) kills the main purpose of cyclone and that'ss serious. I'd
say it even points to a fork in the project. If such a detour in purpose
emerges from the maintenance, maybe we shouldn't call it "cyclone" anymore.

On te other hand, if one is encouraging Max/Msp compatibility breakage,
maybe this person could check first if any user will be affected by that
change. There's me right here, by the way :)

cheers
___
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)

[Jonathan Wilkes via Pd-list]

Hi Fred Jan,Please keep doing what you're doing.
Hi anyone encouraging backward breakage,Please make a collection of as many 
patches as possible, from as many public 
sources as possible.
Then mine this data to get a sense of what percentage of patches would be 
affected 
by changing a Cyclone class' behavior.

Then let's continue with conversation.
If no one is willing to do this, it's a tacit acknowledgement that Fred Jan is 
taking 
the only sensible approach to maintaining Cyclone.

-Jonathan



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

Re: [PD] JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument) JACKerror: JackClient::AcquireSelfRealTime error

[Jonghyun Kim]

added this lines to the end of /etc/security/limits.conf

===
@audio   –  rtprio 99
@audio   –  memlockunlimited
@audio   –  nice  -10
===
sudo usermod -a -G audio MY_USER_ID


On Wed, Dec 23, 2015 at 2:01 AM, Jonghyun Kim  wrote:

> however, no sound problem, no bad messages on qjackctl.
>
> On Wed, Dec 23, 2015 at 1:54 AM, Jonghyun Kim 
> wrote:
>
>> hi list,
>>
>> JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument)
>> JACKerror: JackClient::AcquireSelfRealTime error
>>
>> this errors occurs every pd variants on my system: pd-vanliia 0.46-7,
>> 0.45-4, pd-extended 0.43-4, but no errors with pd-l2ork 20151219(based on
>> pd 0.42? i guess?).
>>
>> my system:
>> ubuntu 14.04-3 LTS 64 bit
>> jackdmp 1.9.10
>> qjackctl 0.3.10
>>
>> thanks,
>> jonghyun kim
>>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument) JACKerror: JackClient::AcquireSelfRealTime error

[Jonghyun Kim]

however, no sound problem, no bad messages on qjackctl.

On Wed, Dec 23, 2015 at 1:54 AM, Jonghyun Kim  wrote:

> hi list,
>
> JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument)
> JACKerror: JackClient::AcquireSelfRealTime error
>
> this errors occurs every pd variants on my system: pd-vanliia 0.46-7,
> 0.45-4, pd-extended 0.43-4, but no errors with pd-l2ork 20151219(based on
> pd 0.42? i guess?).
>
> my system:
> ubuntu 14.04-3 LTS 64 bit
> jackdmp 1.9.10
> qjackctl 0.3.10
>
> thanks,
> jonghyun kim
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument) JACKerror: JackClient::AcquireSelfRealTime error

[Jonghyun Kim]

hi list,

JACKerror: Cannot use real-time scheduling (RR/0)(22: Invalid argument)
JACKerror: JackClient::AcquireSelfRealTime error

this errors occurs every pd variants on my system: pd-vanliia 0.46-7,
0.45-4, pd-extended 0.43-4, but no errors with pd-l2ork 20151219(based on
pd 0.42? i guess?).

my system:
ubuntu 14.04-3 LTS 64 bit
jackdmp 1.9.10
qjackctl 0.3.10

thanks,
jonghyun kim
___
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 

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

[katja]

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 with an obsolete Max/MSP version.
>
>
> If I got it right, you're basically saying:
>
> - Cyclone should be a copy of an outdated and obsolete Max/MSP version and
> we shouldn't care on keeping up with improvements in Max because it is
> impossible and only really likely or reasonably possible within the
> limitations of max/msp 4.6 as a software.
>
> - Not caring about the developments in earlier versions of Max, we're stuck
> to 4.6, but since it is an obsolete version of Max, we shouldn't care about
> being faithful to it either, or Max for that matter.
>
> Thus, we'd basically lose the idea of having a library of objects compatible
> to Max/Msp objects, and we also do not care of the original purpose of it.
> Well, that is not a good take on my opinion.
>
> I agree Cyclone is now (and has always been because of its stage of
> development) a copy/clone of an outdated and obsolete Max/MSP version. That
> is why I think it's good we'd try to keep it up to date with and care on
> keeping up with improvements in Max/Msp