reference to FTM in depot

[equilet]

extras/tutorials/Spectral_Synthesis/CNMAT_Spectral_Tutorials/27-FTM+SDIF.maxpat

I find that there are references to various FTM externals here, and not sure that we want to (or can) support the distribution of FTM externals. I'm communicating w/ @mzed to figure out what the best way forward is... maybe odot?

[adrianfreed]

Maybe try FTM?

I thought I heard that FTM was going away but who knows?

On Sep 27, 2014, at 4:57 PM, Jeffrey Lubow notifications@github.com wrote:

extras/tutorials/Spectral_Synthesis/CNMAT_Spectral_Tutorials/27-FTM+SDIF.maxpat

I find that there are references to various FTM externals here. I'm communicating w/ @mzed to figure out what the best way forward is... maybe odot?

— Reply to this email directly or view it on GitHub.

[equilet]

Try meaning contact them?

[ramagottfried]

as far as I remember, the main reason people use FTM with SDIF is because it’s an easier method to write into the SDIF buffer — we can kind of do that with SDIF-listpoke, but I haven’t had the need to go too deep into the mechanics of it yet.

I believe it’s true that FTM is going away, and replaced by “MuBu" and “PiPo".

On Sep 27, 2014, at 6:26 PM, Jeffrey Lubow notifications@github.com wrote:

Try meaning contact them?

— Reply to this email directly or view it on GitHub.

[adrianfreed]

There is certainly a nice way to transcode SDIF into o. too.

This is on the list of potential things to do for Terraswarm

On Sep 27, 2014, at 6:39 PM, ramagottfried notifications@github.com wrote:

as far as I remember, the main reason people use FTM with SDIF is because it’s an easier method to write into the SDIF buffer — we can kind of do that with SDIF-listpoke, but I haven’t had the need to go too deep into the mechanics of it yet.

I believe it’s true that FTM is going away, and replaced by “MuBu" and “PiPo".

On Sep 27, 2014, at 6:26 PM, Jeffrey Lubow notifications@github.com wrote:

Try meaning contact them?

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[mzed]

When I wrote that, I think I was trying to cover every way I could think of dealing with SDIF in Max. FTM was never part of my own workflow.

At this point, I suspect the Spectral tutorials could use a major overhaul and a 3.0 version. I don't know what the state of the art in SDIF is now, but certainly odot would be addressed. Also, Max 7 is coming.

mz

[equilet]

I'll look at the tutorial in more detail and pose a potential odot approach to what is happening in that patch.

[equilet]

OK, I spent some time creating a little sequencer (based in timetags) that would function as a way to get to/from SDIF. It's not clear to me that this tutorial would benefit from odot. @adrianfreed, unless you can mention specific use cases for odot in what appears to be completely optimized with SDIF, I think I should close this and pull the tutorial.

@mzed, I could also use a little direction in terms of what you were aiming at in this skeleton - I'm not quite sure I understand and it was left before the Max 6 (or 5) version of FTM came about.

[adrianfreed]

Yes, the idea would be to use o.expressions to process streams from SDIF. This was the unrealized vision of SDIF. We realized it a few times in orphaned software like CAST.

On Oct 1, 2014, at 4:05 PM, Jeffrey Lubow notifications@github.com wrote:

OK, I spent some time creating a little sequencer (based in timetags) that would function as a way to get to/from SDIF. It's not clear to me that this tutorial would benefit from odot. Adrian, unless you can mention specific use cases for odot in what appears to be completely optimized with SDIF, I think I should close this and pull the tutorial.

@mzed, I could also use a little direction in terms of what you were aiming at in this skeleton - I'm not quite sure I understand and it was left before the Max 6 (or 5) version of FTM came about.

— Reply to this email directly or view it on GitHub.

[ramagottfried]

I was thinking the other day that it would be great to have something like sdif-tuples in odot and be able to lookup bundle by timetag, and interpolate where appropriate. maybe this is something o.table would do eventually?

On Oct 1, 2014, at 7:55 PM, Adrian Freed notifications@github.com wrote:

Yes, the idea would be to use o.expressions to process streams from SDIF. This was the unrealized vision of SDIF. We realized it a few times in orphaned software like CAST.

On Oct 1, 2014, at 4:05 PM, Jeffrey Lubow notifications@github.com wrote:

OK, I spent some time creating a little sequencer (based in timetags) that would function as a way to get to/from SDIF. It's not clear to me that this tutorial would benefit from odot. Adrian, unless you can mention specific use cases for odot in what appears to be completely optimized with SDIF, I think I should close this and pull the tutorial.

@mzed, I could also use a little direction in terms of what you were aiming at in this skeleton - I'm not quite sure I understand and it was left before the Max 6 (or 5) version of FTM came about.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[adrianfreed]

You have framed it as a file operation when SDIF was specifically oriented for streaming. It would be good to support both models but some thought is required for the api. We are working on a matrix type for OSC which would make the transcoding trivial.

On Oct 1, 2014, at 8:06 PM, ramagottfried notifications@github.com wrote:

I was thinking the other day that it would be great to have something like sdif-tuples in odot and be able to lookup bundle by timetag, and interpolate where appropriate. maybe this is something o.table would do eventually?

On Oct 1, 2014, at 7:55 PM, Adrian Freed notifications@github.com wrote:

Yes, the idea would be to use o.expressions to process streams from SDIF. This was the unrealized vision of SDIF. We realized it a few times in orphaned software like CAST.

On Oct 1, 2014, at 4:05 PM, Jeffrey Lubow notifications@github.com wrote:

OK, I spent some time creating a little sequencer (based in timetags) that would function as a way to get to/from SDIF. It's not clear to me that this tutorial would benefit from odot. Adrian, unless you can mention specific use cases for odot in what appears to be completely optimized with SDIF, I think I should close this and pull the tutorial.

@mzed, I could also use a little direction in terms of what you were aiming at in this skeleton - I'm not quite sure I understand and it was left before the Max 6 (or 5) version of FTM came about.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[ramagottfried]

oh! interesting — I guess just my main use cases with SDIF in max have always been storage and playback, either of an analysis or wanting to store and playback large amount of data, e.g. SpatDIF. Actually if I recall correctly, SpatDIF converts everything to OSC when playing back.

On Oct 2, 2014, at 12:49 AM, Adrian Freed notifications@github.com wrote:

You have framed it as a file operation when SDIF was specifically oriented for streaming. It would be good to support both models but some thought is required for the api. We are working on a matrix type for OSC which would make the transcoding trivial.

On Oct 1, 2014, at 8:06 PM, ramagottfried notifications@github.com wrote:

I was thinking the other day that it would be great to have something like sdif-tuples in odot and be able to lookup bundle by timetag, and interpolate where appropriate. maybe this is something o.table would do eventually?

On Oct 1, 2014, at 7:55 PM, Adrian Freed notifications@github.com wrote:

Yes, the idea would be to use o.expressions to process streams from SDIF. This was the unrealized vision of SDIF. We realized it a few times in orphaned software like CAST.

On Oct 1, 2014, at 4:05 PM, Jeffrey Lubow notifications@github.com wrote:

OK, I spent some time creating a little sequencer (based in timetags) that would function as a way to get to/from SDIF. It's not clear to me that this tutorial would benefit from odot. Adrian, unless you can mention specific use cases for odot in what appears to be completely optimized with SDIF, I think I should close this and pull the tutorial.

@mzed, I could also use a little direction in terms of what you were aiming at in this skeleton - I'm not quite sure I understand and it was left before the Max 6 (or 5) version of FTM came about.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[equilet]

OK. I'm going to meet with @adrianfreed about this, and we can settle on a couple simple implementations that help get people started. This can replace the FTM tutorial, and I'll update the rest of the suite to reflect this. A bit problematic, IMO, as this reference to odot comes at the very end of the series, bypassing an opportunity to introduce odot earlier on... Maybe @mzed and I could meet a bit to have me update these materials, if there is funding for it.

[mzed]

Another historical note. Originally, the OSC tutorials were part of the Spectral Series. They got pulled out later because it seemed like a good idea to have a series focussed on synthesis and another focussed on control.

I don't really know the state of the art at CNMAT. It seems like o.dot could use its own tutorials, as it has many applications beyond synthesis control. Any synthesis-specifc features might be linked in the Spectral Tutorials, or something.

Since I no longer work at CNMAT, use Max, or make music, I have no horse in this race.

mz

[equilet]

Thanks for your input. Yes, I think that the spectral tutorials should be updated to showcase the way odot might be utilized in these contexts, but there are in fact other odot tutorials, including a wonderful intro that @adrianfreed made around the time of MMJSS this year.

[equilet]

I'll be removing this tutorial... I'm opting to simply renumber (including a version bump). There may be an opportunity in the future to place odot in the context of Spectral Synthesis tutorials, but the goal of this particular issue was to resolve FTM's presence in our distribution.