Pure Data - add getname method for fluid.dataset - as in Max

[marcodsad]

Is your feature request related to a problem? Please describe the problem.

I’m using fluid.dataset in dynamically-created abstractions in Pd.
While all fluid.buffer objects work well when using $0-buffers, fluid.dataset doesn't recognize a buffer named dynamically in that way. This seems to me a bit incoherent, but I assume it is a dictated by some implementation need.

Nevertheless, @weefuzzy mentioned that fluid.dataset does give a random name to its buffer when no argument is provided and that in Max it is possible to query this name with the method getname. Presently, this method is not implemented in Pd.

Describe the solution you'd like to see.

Not knowing the source code of fluid.dataset or flucoma, I assume implementing the getname method in Pd would be the easiest solution?

Describe alternatives you've considered

That said, it would be even neater if fluid.dataset could work with $0-buffers so it'd integrate perfectly with Pd as the other fluid.buffer objects already do. But that's probably a lot more work.

Additional context

My own context of development is an instrument that creates dynamically macro abstractions capable of analysing, extracting features and create navigable datasets from different media folders. This would also allow to apply the same operation to music being played live for example, or to create a sort of memory for the instrument.

[weefuzzy]

Hiya,

Given how soon your première is, it's probably worth trying to focus on the simplest solution to your needs: my instinct is that figuring out what's up with $0 will be easier than implementing the C++ template goo needed for implementing getname properly (though we ought to anyway).

To confirm, are you experiencing that using $0 in a dataset name isn't working, e.g. [fluid.dataset $0-foo]? I think it should work, so perhaps it's related to the dynamically created abstractions (screenshot below of basic idea working, courtesy of @tremblap)

[tremblap]

sorry for the naming - it was private to owen :)

[marcodsad]

heya both, thanks for the prompt reply. So, indeed, you are right and I'm in the wrong! sorry.
fluid.dataset $0-caca does indeed work (@tremblap that made me smile :P). What was happening was that fluid.dataset would complain DataSet is empty, so i thought it was the $0 pointing the object to an inexistent dataset. But it was the messaging to the object instead (my dynamic addpoint method was buggy and didn't fill the dataset).

So, as @weefuzzy suggested, the problem was in my naming for the methods of fluid.dataset, which now I've fixed, and so the abstraction works.

Sorry for the noise, it was helpful though to talk with you to make me understand the problem.

What should i do with this thread here? close it, delete it, leave it...
i'm not sure we need getname in pd since $0 works out of the box? and it's definitely more a Pd'ish way of doing things.

by the way, gonna take this chance to tell you that after having used quite a bit now flucoma in pd (and reaper/cmd) I'm grateful for the attention you put into integrating everything in Pd. The integration, as well as the help files, are really well thought and neatly done. Not everyone working on a cross-platform lib makes that kind of effort.

It's a pity there aren't flucoma tutorials for Pd online - if I had time, I'd do it, not for now sadly! - because the lib is awesome and powerful. it took me quite a bit of time to 'port' some max tutorials. But it was really worth it :D

[weefuzzy]

Thanks for the kind words and confirmation! Credit for the attention to detail in PD definitely goes to @tremblap and his tenacity. We'll make a note also about porting tutorials, and see if there's other members of the flucoma-pd community that might be interested to contribute to that effort.

Let's keep this FR open, because I think one should be able to query the state of stateful things as a general principle :-)

Good luck with the piece, meanwhile...

[weefuzzy]

So, whilst it's on my mind: the general job here is to implement a generic get<X> selector in the pd wrapper that will report parameter values. This should be doable in the context of the existing SetupAttribute compile-time 'loop'. Open questions:

• interface: is there an existing idiom from other PD objects that offer attribute-like interfaces that would steer us away from using get<param name> as a selector? (e.g. get <param name> instead? which would be more complicated)
• do we already have a generic 'dump' outlet in PD?

Conditionally a 'good first issue' for anyone not-terrified of the wrapper...

[tremblap]

Thanks for the creds both. Porting the tutorials has been on my todo list for a year. It'll happen soon I hope.

[marcodsad]

Thanks for the creds both. Porting the tutorials has been on my todo list for a year. It'll happen soon I hope.

would be happy to help, it's just about (for me) finding a good period of the year when I've got time.
Please keep me posted.