mixing obex and jitter api's

Jan 25, 2008 at 4:28pm

mixing obex and jitter api's

I was adding a filter to a Jitter objects’ attribute, which I’d done before
with obex objects, and found that the official Jitter way of doing that is a
lot more cumbersome than the obex way. So instead I tried using the obex
functions and it seems to be fine. Something like:

attr = attr_offset_new(“output_mode”, _jit_sym_long, attrflags, (method)0L,
(method)0L, calcoffset(c, output_mode));
attr_addfilter_clip(attr, 0, 2, 1, 1);
jit_class_addattr(c ,attr);

For most of the obex stuff there is a kind of jit_ equivalent, which makes
me think the obex API was evolved from the Jitter API for a big part.

And am I right in my assumption that it doesn’t hurt to replace Jitter API
functions with the obex equivalent?

Are these API ambiguities resolved for Max5?

Thijs

#35516
Jan 25, 2008 at 5:13pm

On Jan 25, 2008, at 8:28 AM, Thijs Koerselman wrote:

> For most of the obex stuff there is a kind of jit_ equivalent,
> which makes me think the obex API was evolved from the Jitter API
> for a big part.

You are correct.

> And am I right in my assumption that it doesn’t hurt to replace
> Jitter API functions with the obex equivalent?

It should be fine within the jitter class, but there will most likely
be issues if you are trying to intermingle with the Max wrapper class
(which uses some dumb legacy implementation for attributes which is
not compatible with obex at the moment). Let us know if you
experience any issues.

> Are these API ambiguities resolved for Max5?

Nope. We need both. Otherwise old objects wouldn’t work using the
jitter calls.

-Joshua

#121162
Jan 25, 2008 at 5:34pm

On Jan 25, 2008 5:13 PM, Joshua Kit Clayton wrote:

>
> It should be fine within the jitter class, but there will most likely
> be issues if you are trying to intermingle with the Max wrapper class
> (which uses some dumb legacy implementation for attributes which is
> not compatible with obex at the moment). Let us know if you
> experience any issues.
>
> > Are these API ambiguities resolved for Max5?
>
> Nope. We need both. Otherwise old objects wouldn’t work using the
> jitter calls.
>

Thanks for confirming Joshua. I’ll keep using obex and report any issues in
case I run into them.

I personally hope at some point Cycling decides to drop backwards
compatibility. I couldn’t care less about it. Rewrite the scheduler, clean
up the API’s and we all live happily ever after! I’ll volunteer to port any
crucial 3rd party externals :-)

Thijs

#121163
Jan 25, 2008 at 6:08pm

>I personally hope at some point Cycling decides to drop backwards
compatibility. I couldn’t care less about it. Rewrite the scheduler,
clean up the API’s and we all live happily ever after! I’ll >volunteer
to port any crucial 3rd party externals :-)

I strongly agree with Thijs on this one.

Backward compatibility issues seem to have become a big hold-back for many aspects of Max.
I too couldn’t care less about backward compatibility, and would want to make Max/MSP/Jitter more efficient and easier to maintain for C74.

If user patches will break and 3rd party externals will have to be rewritten, so be it.
I think it comes a time when we gotta spend the time and upgrade our stuff, as an investment for future development.

… and, yes, we’ll all live happily there after.

- Luigi

————————————————————
THIS E-MAIL MESSAGE IS FOR THE SOLE USE OF THE INTENDED RECIPIENT AND MAY CONTAIN CONFIDENTIAL AND/OR PRIVILEGED INFORMATION. ANY UNAUTHORIZED REVIEW, USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, CONTACT THE SENDER BY E-MAIL AT SUPERBIGIO@YAHOO.COM AND DESTROY ALL COPIES OF THE ORIGINAL MESSAGE. WITHOUT PREJUDICE UCC 1-207.
————————————————————

—– Original Message —-
From: Thijs Koerselman

Sent: Friday, January 25, 2008 9:34:42 AM
Subject: Re: [dev] mixing obex and jitter api’s

On Jan 25, 2008 5:13 PM, Joshua Kit Clayton wrote:

It should be fine within the jitter class, but there will most likely
be issues if you are trying to intermingle with the Max wrapper class
(which uses some dumb legacy implementation for attributes which is

not compatible with obex at the moment). Let us know if you
experience any issues.

> Are these API ambiguities resolved for Max5?

Nope. We need both. Otherwise old objects wouldn’t work using the

jitter calls.

Thanks for confirming Joshua. I’ll keep using obex and report any issues in case I run into them.

I personally hope at some point Cycling decides to drop backwards compatibility. I couldn’t care less about it. Rewrite the scheduler, clean up the API’s and we all live happily ever after! I’ll volunteer to port any crucial 3rd party externals :-)

Thijs

Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

#121164
Jan 25, 2008 at 6:23pm

On Jan 25, 2008, at 10:08 AM, Luigi Castelli wrote:

> >I personally hope at some point Cycling decides to drop backwards
> compatibility. I couldn’t care less about it. Rewrite the
> scheduler, clean up the API’s and we all live happily ever after!
> I’ll >volunteer to port any crucial 3rd party externals :-)
>
> I strongly agree with Thijs on this one.
>
> Backward compatibility issues seem to have become a big hold-back
> for many aspects of Max.
> I too couldn’t care less about backward compatibility, and would
> want to make Max/MSP/Jitter more efficient and easier to maintain
> for C74.

This is in my opinion a highly speculative assumption. I’m personally
curious as to what do you perceive to be held back? For instance the
scheduler implementation has nothing to do with backward
compatibility. There’s typically no fundamental reason why any
software can’t be backwards compatible. It’s usually just a tradeoff.
For example, there is no backward compatibility in Max 5 for UI
externals, since it’s not deemed worth implementation or maintenance.
And there are places over the years where we have made decisions

However wholesale elimination of functional APIs that are not a
maintenance issue in order to have a sense of API purity, is an
incredibly narrow sighted view, and seems to place more importance on
cosmetics or ideology, than practical issues or actually making high
quality software.

-Joshua

#121165
Jan 25, 2008 at 8:14pm

On Jan 25, 2008 6:23 PM, Joshua Kit Clayton wrote:

This is in my opinion a highly speculative assumption. I’m personally
> curious as to what do you perceive to be held back? For instance the
> scheduler implementation has nothing to do with backward
> compatibility.

I vaguely remember backwards compatibility came up in a earlier discussion
as one of the reasons why the scheduler was not changed for Max5. Forgive me
if I’m wrong.

> However wholesale elimination of functional APIs that are not a
> maintenance issue in order to have a sense of API purity, is an
> incredibly narrow sighted view, and seems to place more importance on
> cosmetics or ideology, than practical issues or actually making high
> quality software.
>

I agree that the API is a trivial thing. Of course I’m not seriously
bothered about that in any way. That said, I think that over the years a lot
of different coding styles and techniques have gathered in the SDK and
examples, making it a bit confusing since there are sometimes several ways
to do the same thing. Having a cleaner more unified API will benefit new and
less experienced developers in my opinion.

I got the impression that Cycling in general is very careful about breaking
backwards compatibility, and all I’m saying is that I don’t care.

I’m very excited about Max5, don’t get me wrong!

Best,
Thijs

#121166
Jan 25, 2008 at 9:56pm

Quote: thijs.koerselman wrote on Fri, 25 January 2008 21:14
—————————————————-
> I got the impression that Cycling in general is very careful about breaking
> backwards compatibility, and all I’m saying is that I don’t care.
—————————————————-

That’s all well and good, but there are people who *do* care.

Although I have always taken care to write code with a high degree of encapsulation and a change to the API *might* only require a single change in a single place, I’m not taking any bets. With over 100 objects to maintain, there will be plenty to do with the slightest changes whatsoever.

>I’ll volunteer to port any crucial 3rd party externals :-)

Be careful what you volunteer for. Someone might take you up on it.

#121167
Jan 25, 2008 at 10:22pm

On Jan 25, 2008 9:56 PM, Peter Castine

wrote:

>
> Quote: thijs.koerselman wrote on Fri, 25 January 2008 21:14
> —————————————————-
> > I got the impression that Cycling in general is very careful about
> breaking
> > backwards compatibility, and all I’m saying is that I don’t care.
> —————————————————-
>
> That’s all well and good, but there are people who *do* care.
>
>
Yes Peter I understand there are loads of people who *do* care. And I think
its only fair to be careful on such things, but if its for the greater good
like an improved scheduler, I’d say its well justified. I’m aware that this
is just a personal opinion, and that it won’t affect me nearly as much as
others. That’s why I initially wrote “I personally hope..”

I should have known my comment was going to provoke a discussion like this.
It wasn’t intended like that, since it’s rather pointless. Stupid of me.

> Be careful what you volunteer for. Someone might take you up on it.
>
> I’m not even joking. To some degree I’d be happy to help out. As long as
the externals are adding something essential to the standard objects. Since
I use Litter Pro myself you’re definitely nominated ;-)
Thijs

#121168
Jan 28, 2008 at 1:55pm

Fair enough, there’s not much point in having an extended pros vs. cons discussion of backwards compatibility. I just didn’t want to leave what seemed to be a rather blanket statement hanging in the air unchallenged.

My perspective is colored by quite a few breaks with backwards compatibility in the course of 18 years or so of writing patches and externals for Max. Even fairly minor things, like the change in handling of float input to externals that occurred about a decade ago, cost me many hours to track down & identify, in this case exacerbated by the lack of any documentation in the change that I could find. There was also a change in delay’s behavior, again lost in the clouds of antiquity, that broke a few patches until I figured out what was going on.

Sometimes it is, indeed, necessary to make changes. There are some changes that would be a certain amount breakage & suffering. But the pros & cons need to be weighed against each other.

At the end of the day, neither you nor I will be the ones weighing pros & cons and deciding what to break. Indeed, I expect most of the breakage decisions have long since been made.

Cheers — P.

#121169

You must be logged in to reply to this topic.