Hi all, i'd like to ask about the current state of FTM for PD. From looking into the SVN repo it's obvious that a considerable amount of work has already been put into it, but it doesn't compile right away, so i'm not sure if it's still maintained or if there's anything more fundamental missing. For me, only the underlying FTMlib and the ftm.object and ftm.mess objects are really required. thanks, gr~~~
Hi Thomas,
On 3 sept. 10, at 13:42, Thomas Grill wrote:
Hi all, i'd like to ask about the current state of FTM for PD. From looking into the SVN repo it's obvious that a considerable
amount of work has already been put into it, but it doesn't compile
right away, so i'm not sure if it's still maintained or if there's
anything more fundamental missing.
Yes, I think the latest state of the development of FTM for Pd was
already pretty close (since the last adaptations to Max 5 we probably
took back a little distance).
But no, we have currently no plans to develop this further.
In fact, I didn't have the impression, that Pd "needs" FTM very much,
since there are other approaches for handing "complex" data structures.
For what concerns the Gabor and MnM libraries, that have certainly
some interesting functionalities that would be worth having in Pd, I
also could imagine alternative ways to integrated them into Pd (as
well as into Max/MSP/Jitter) relying on the data structures that are
already existing in these environments.
For me, only the underlying FTMlib and the ftm.object and ftm.mess
objects are really required.
Can you develop more on this point?
Best N.
thanks, gr~~~
Hi Norbert,
Yes, I think the latest state of the development of FTM for Pd was already pretty close (since the last adaptations to Max 5 we probably took back a little distance). But no, we have currently no plans to develop this further.
In fact, I didn't have the impression, that Pd "needs" FTM very much, since there are other approaches for handing "complex" data structures.
Well, the basic built-in possibilities may be there but they haven't been developed into a convenient higher-level system. The VASP modular system that i have been developing for a while is similar to FTM but i don't have the time to maintain it any more and i would rather port the higher-level portions to FTM. I think that Pd needs FTM as much as Max needs it and i would appreciate patcher-level cross-platform compatibility a lot.
For what concerns the Gabor and MnM libraries, that have certainly some interesting functionalities that would be worth having in Pd, I also could imagine alternative ways to integrated them into Pd (as well as into Max/MSP/Jitter) relying on the data structures that are already existing in these environments.
Certainly, but do you plan to open-source them?
For me, only the underlying FTMlib and the ftm.object and ftm.mess objects are really required.
Can you develop more on this point?
It means that at this point i personally don't need mnm or gbr externals. The basic FTM functionality is sufficient - i would probably make a Python binding and use numpy/scipy for higher level stuff.
gr~~~
On 6 sept. 10, at 12:12, Thomas Grill wrote:
Hi Norbert,
Yes, I think the latest state of the development of FTM for Pd was
already pretty close (since the last adaptations to Max 5 we probably took
back a little distance). But no, we have currently no plans to develop this further.In fact, I didn't have the impression, that Pd "needs" FTM very
much, since there are other approaches for handing "complex" data structures.Well, the basic built-in possibilities may be there but they haven't been developed into a convenient higher-level system. The VASP modular system that i have been developing for a while is similar to FTM but i don't have the time to maintain it any more and i would rather port the higher-level portions to FTM. I think that Pd needs FTM as much as Max needs it and i would appreciate patcher-level cross-platform compatibility a lot.
Unfortunately, the development of FTM has similar resource issues.
For the moment, we maintain FTM & Co in it's current state and add
very minor features when they don't add anything that makes the
maintenance more difficult.
For what concerns the Gabor and MnM libraries, that have certainly
some interesting functionalities that would be worth having in Pd, I
also could imagine alternative ways to integrated them into Pd (as well as into Max/MSP/Jitter) relying on the data structures that are already
existing in these environments.Certainly, but do you plan to open-source them?
"Plan" is certainly not the right word, but I think, open source
licensing has to be seriously (re-)discussed in this context.
For me, only the underlying FTMlib and the ftm.object and ftm.mess
objects are really required.Can you develop more on this point?
It means that at this point i personally don't need mnm or gbr externals. The basic FTM functionality is sufficient - i would probably make a Python binding and use numpy/scipy for higher level stuff.
Ok.
Currently, we don't have the resources for this, but of course we
would continue to support whoever who would like to continue to work
in this direction as good as I can.
N.
gr~~~ FTM & Co wiki: http://ftm.ircam.fr/ mailing-list: http://listes.ircam.fr/wws/info/ftm bug reports: mailto:ftm-bugs@ircam.fr
-
Norbert Schnell -
Thomas Grill