danieleghisi

There have already been some posts on the subject, but I've found no answer to these questions.

- What's the reason why there's no [curve] object in Max? That would be so easy to write - and indeed I know different people who have done their own curve abstraction/objects. That absolutely makes no sense to me: it should be a standard object, and that would be very easy to do...

- Why do I have to use [ej.line] to have multiple-segmented lines? The [line] object should take care of it. This is also something basic, which should be possible inside the standard collection of objects.

In general, I can't understand the broken symmetries between the couple [line~]-[curve~], which works great, and the couple [line]-[curve], whose second element is even missing.

I really hoped that Max 6 was fixing this lacks, but apparently it does not. Since it's less than 1 day work, I'm wondering why: is there a profound reason? Backward compatibility would be preserved...

again-curve-and-line

i cannot agree more. i expect every max user agrees with you.

however, you say "Since it's less than 1 day work" and you are theoretically correct, but in fairness to cycling74 they seem to take adding a new object very seriously, and so it takes a long time, testing and checking it fits in. although this issue you mention has been around for years, granted!

what i find really really frustrating is when objects that the entire max community around the world would surely 100% back being in the main distro - ej.line, ej.function - are actually made by a cycling74 employee, and STILL they are not ported to C and included. it drives me mad.

man i am having a whinging day today. just wanted to back you up.

...no "official" answer from cycling about this?

bump...
...no "official" answer from cycling about this?


If you can do a [curve] with a simple abstraction, then why not just use the simple abstraction?

 presume to know how much work is involved with any change to Max/MSP. Creating a new object involves not only development and testing, but documentation. I know that I've written some Litter Power objects in less than an hour, but until they were ready for prime time… (Anecdote: I recall having a chat with Jørgen and Trond at BEK, saying, "hey, that gives me an idea for an object," going away and coming back with the new object working to find Jørgen and Trond still in the same conversation. But by the time I'd written up help patches, added entries into the Thesaurus, added references to related objects, and all the other requisite documentation, the conversation was over, I wasn't even in the same country, and a year had gone by.) In terms of Cycling '74 objects, coordinating new objects with documentation also means coordinating the work of different people residing on different places on the planet.

About line: can you guarantee (as in "are you prepared to stake your life on it") that the change you propose will not effect existing patches? Are you prepared check and update every existing patch in the world that might be effected by the change? It's hardly as if you're the first person to have had the idea.

Rule #1: never, never ever presume to know how much work is involved with any change to Max/MSP. Creating a new object involves not only development and testing, but documentation. I know that I've written some Litter Power objects in less than an hour, but until they were ready for prime time… (Anecdote: I recall having a chat with Jørgen and Trond at BEK, saying, "hey, that gives me an idea for an object," going away and coming back with the new object working to find Jørgen and Trond still in the same conversation. But by the time I'd written up help patches, added entries into the Thesaurus, added references to related objects, and all the other requisite documentation, the conversation was over, I wasn't even in the same country, and a year had gone by.) In terms of Cycling '74 objects, coordinating new objects with documentation also means coordinating the work of different people residing on different places on the planet. 

About line: can you guarantee (as in "are you prepared to stake your life on it") that the change you propose will not effect existing patches? Are you prepared check and update every existing patch in the world that might be effected by the change? It's hardly as if you're the first person to have had the idea.


Peter, I see your points, but I really don't understand them:

- I can do it with an abstraction. Yet, this is way slower. And waaaaay less efficient.

- I completely understand the great effort for documentation, but these features appear to me as a base brick for the system. Plus: Cycling '74 has done many a new object within the years, and frankly I hope that those objects are NOT only missing because "it takes time to document them".

Of course I'm sure I'm not the first person having this idea, but this forum is the only way I had to check if I was the only one feeling this lack.

The curve object did not exist before, so backward compatibility is preserved (unless, of course, if one has used the same name for a personal abstraction, but frankly this issue is the same when adding any new object). And, even if it seems to me that it *should* be so, of course I can't *guarantee* that every patch will behave exactly the same way, since only cycling knows what's inside the code. I'm an user, not a developer, and I'm just pointing out a weird asymmetry, just trying to understand *why* these basic features are lacking.

Peter, I see your points, but I really don't understand them:
- I can do it with an abstraction. Yet, this is way slower. And waaaaay less efficient.
- I completely understand the great effort for documentation, but these features appear to me as a base brick for the system. Plus: Cycling '74 has done many a new object within the years, and frankly I hope that those objects are NOT only missing because "it takes time to document them".

Of course I'm sure I'm not the first person having this idea, but this forum is the only way I had to check if I was the only one feeling this lack. 

The curve object did not exist before, so backward compatibility is preserved (unless, of course, if one has used the same name for a personal abstraction, but frankly this issue is the same when adding any new object). And, even if it seems to me that it *should* be so, of course I can't *guarantee* that every patch will behave exactly the same way, since only cycling knows what's inside the code. I'm an user, not a developer, and I'm just pointing out a weird asymmetry, just trying to understand *why* these basic features are lacking.


Many years ago, as others, I made an abstraction which does that and realized it was trickier than I thought initially. The first issue ej.line has… it sucks at timing ;-) which is kinda bad but that's one way of doing it "properly". Sometimes you don't care about having the grain being the same size then it's fairly easy, but line always have a constant grain size which cause the points either to be moved on the grain size "sample rate" or adding new grains for each target segment which can cause some other problems when the segments are too small. Suddenly not as easy as it seems ;-)

@Emmanuel, thanks for registering Daniele's wishes as a feature request. Sorry I bombastically entered thread with regards your objects. I also appreciate these things are tricky.

@Peter: yet another arrogant post that is designed to make yourself look intelligent and important. Besides, lecturing @danieleghisi on that is sort of insulting considering he is co-producer of one of the most amazing (and well documented) third-party Max libraries in the history of the software. Jeez.

I've made an mxj of the gen4 curve. (rtcmix gen4 - make a function from line segments with adjustable curvatures for every segment).

I can share it in a few days if anyone here is interested ..

I've made an mxj of the gen4 curve. (rtcmix gen4 - make a function from line segments with adjustable curvatures for every segment). 

I can share it in a few days if anyone here is interested ..


Thanks emmanuel for registering the feature request, that is cool.

And thanks ullrich for the your helpfulness: indeed, I do have a personal "curver" abstraction doing the trick (but working roughly and with a formula which is probably NOT cycling's one), I was only curious to know why [curve] is not in the distribution. Yet, since my abstraction is veeery rough, I'd be interested to have a look at yours, which definitely seems better.

Thanks emmanuel for registering the feature request, that is cool.
Thanks pid for your very kind words!
And thanks ullrich for the your helpfulness: indeed, I do have a personal "curver" abstraction doing the trick (but working roughly and with a formula which is probably NOT cycling's one), I was only curious to know why [curve] is not in the distribution. Yet, since my abstraction is veeery rough, I'd be interested to have a look at yours, which definitely seems better.


https://cycling74.com/forums/share-gen4-mxj-make-line-segments-with-adjustable-curvatures

I agree with Daniele, often I need of a multi-segmented line object and used ej.line for that. I also made my own abstraction for that and saw that the problem wasn't to simple to manage, as Emmanuel says, for timing or grain or precision problems.

So i add my vote for a multi segmented line objet in C.

So i add my vote for a multi segmented line objet in C.
Cheeeeeers


I feel I need to add a further note on this subject.

It's true: you can easily use ej.line or do your own [curve] abstractions. But when you need to create a coherent library or set of abstraction (which is the case for me right now), you need it to rely on the minimum number possible of libraries. Possibly none.

I surely don't want to ask my users to install a 3rd party library just to have a multisegmented line (even if ej-ies are great!). It makes no sense. Also I cannot add a [multiline] or [curve] abstraction in the set, whereas all other abstractions are focused on specific notation issues. It makes no sense either.

I kind of feel to be "left alone", with no clean solution (...it even crossed my mind to sample a [curve~] object...)... Much better to allow for different grain sizes for each segment than not to have any way to accomplish the task ;-)

Emmanuel, just out of curiosity, what's the state of the feature request? :-) Are we likely to see it in a forecastable future?

Hi @Danieleghisi, your post should be back up now.

If it's so easy and "less than one day of work" why haven't you coded your own external in C to do it? After all that was one of the original intentions of Max: to act as a modular environment to connect pieces of C code (externals) together. Don't wait for the company, roll your own solution.

Hi stringtapper, (@ginger: thanks a lot!)

I'd gladly code it, but, as I just explained in my last reply, this is not at all the point.

The point is that when you write a Max library focused on one specific thing (in this case: musical notation), it makes no sense at all to include stuff doing what ej.line does. Also you need the library to rely on the *minimum* number of additional libraries: I'd really don't want to force people downloading other additional stuff just to make segmented lines.

My opinion is that modularity is good, provided that basic behaviors are all included in the "main distribution", and I think of this as a basic behavior (after all line~ does it, so one would expect to have the same feature in the non-audio domain).

Also, it seems to me that I have just restated my previous post...

Addition, @stringtapper: it seems that this thread has been shortened: just the original message has been kept, and my other messages and other people's replies have been deleted. So when I said "in my last reply", actually that reply had disappeared! :-)

Hey again @danieleghisi, sorry for the trouble. The previous posts should also be back up now.

Yeah there was a lot of context missing from the thread when I posted!

Again: curve and line