maxversion get bit

Jan 9, 2009 at 3:49pm

maxversion get bit

Hello,

I’m trying to test to see if I’m running inside a standalone, the documentation suggests using maxversion(), and querying the 14th bit. I’m afraid my C knowledge doesn’t stretch this far! Would anybody be kind enough to quickly show me how to get this 14th bit in to a regular boolean variable? I’ve been googling for several hours without any success…

Many thanks,
Simon

#41611
Jan 9, 2009 at 4:26pm

Hello,

have a look at this:

http://en.wikipedia.org/wiki/Mask_(computing)#Querying_the_status_of_a_bit

To query the 14-th bit, I suppose the bit mask should be 0×2000 (in
decimals, this is 2^13 = 8192), but somebody pls. correct me if I’m
wrong.

Cheers,
Adam

On 2009.01.09., at 16:49, simon adcock wrote:

>
> Hello,
>
> I’m trying to test to see if I’m running inside a standalone, the
> documentation suggests using maxversion(), and querying the 14th
> bit. I’m afraid my C knowledge doesn’t stretch this far! Would
> anybody be kind enough to quickly show me how to get this 14th bit
> in to a regular boolean variable? I’ve been googling for several
> hours without any success…
>
>
> Many thanks,
> Simon
>

#148255
Jan 9, 2009 at 6:58pm

A macro will do it:

#define GETBIT14(x) x & 8192

then you can do:

if(GETBIT14(x))
// The bit was set to 1
else
// The bit was set to 0

best,

Jamie

On 9 Jan 2009, at 15:49, simon adcock wrote:

>
> Hello,
>
> I’m trying to test to see if I’m running inside a standalone, the
> documentation suggests using maxversion(), and querying the 14th
> bit. I’m afraid my C knowledge doesn’t stretch this far! Would
> anybody be kind enough to quickly show me how to get this 14th bit
> in to a regular boolean variable? I’ve been googling for several
> hours without any success…
>
>
> Many thanks,
> Simon

#148256
Jan 12, 2009 at 4:06pm

Or, if you prefer inlines (which buy you type-checking, something that has saved me a lot of heartache), here, straight from the Litter Power source code, with permission of the author:

static inline short
LitterGetMaxVersion(void)
{ return maxversion() & 0x3fff; } // Mask out standalone flag

static inline Boolean
LitterInsideStandalone(void)
{ return (maxversion() & 0×4000) != 0; }

#148257
Jan 16, 2009 at 8:26pm

Thanks for the suggestions, unfortunately I still can’t get it to work. Using the code below, in the Max window I get: “MaxVersion: 1285″, and “not in standalone”. Both inside Max and inside an .exe

I don’t really know what I’m doing when it comes to bits and masks, if you don’t mind having a quick look that would be so helpful.

Many thanks,
Simon
(Windows XP, Max 5.05)

// In the struct…

static inline short LitterGetMaxVersion(void) { return maxversion() & 0x3fff; }

static inline Boolean LitterInsideStandalone(void){ return (maxversion() & 0×4000) != 0; }

// Later…

void isStandalone_bang(t_minimum *x)
{
post(“maxversion: %d”, x->LitterGetMaxVersion());

if(x->LitterInsideStandalone())
{
post(“in standalone”);
}
else
{
post(“not in standalone”);
}
}

#148258
Jan 16, 2009 at 11:00pm

The return value of 1285 makes perfect sense.

It might make more sense to you if you post()ed it in hex.

post(“maxversion: %x”, x->LitterGetMaxVersion());

would print 505 in the Max window. If you want dots between the hex digits, you will need to do some string manipulation yourself.

I had another look at the documentation, and it is a little confusing. “Bit 14 (counting from left) will be set if Max is running as a standalone application…”

Conventionally bits are numbered from least significant to most significant, and this is usually counting from the *right* (not from the left). Also by convention, the least significant bit is numbered zero. These two conventions have the convenience that bit N is equal to 2^N. Specifically, Bit 14 would be 2^14, which is 16,384.

It is these conventions that my code is based on.

However, the SDK goes on to say “…, so you should mask the lower 12 bits to get the version number.”

If only the lower 12 bits apply to the version number (in hex), that would imply that the magic standalone bit should be Bit *12* (remember, we start counting bits at zero, so 0-11 are the lower twelve, and Bit 12 is the next one up).

I see I have another version of the two utility functions in another project where I use 0x0fff as the version mask and 0xf000 as the standalone-bit mask (actually checking if any of the top four bits is set). One of the two versions has been tested, but now I’m not sure which.

Failing an authoritative word from someone who can check the source code to maxversion(), why don’t you run the following line inside your standalone:


post(“maxversion() returns 0x%x”, maxversion());

Will the real standalone bit please stand up.

#148259
Jan 17, 2009 at 9:46am

Thanks Peter, strange… Hopefully there’ll be an authoritative word from someone…

post(“maxversion() returns 0x%x”, maxversion());
gives: “0×505″ in both standalone and Max.

“0xf000″ didn’t seem to work either.

Simon

#148260
Jan 17, 2009 at 5:20pm

Quote: simon adcock wrote on Sat, 17 January 2009 10:46
—————————————————-
> post(“maxversion() returns 0x%x”, maxversion());
> gives: “0×505″ in both standalone and Max.

In that case the standalone bit, whichever position it has, is not being set. Period.

> “0xf000″ didn’t seem to work either.

Which follows necessarily from the above.

I think the issue warrants a bug report.

The good news is that the hex 505 confirms you’re running Max/MSP 5.0.5, as you said.

There was an alternative method for determining whether or not you are running in a non-editable context (ie either collective or standalond). I think it involved try to get the address of an API function that is only available with the full Max engine and testing it against NULL. Unfortunately I don’t remember details and I never implemented it. Some clever Googling might turn it up.

#148261
Jan 20, 2009 at 9:23pm

This was a bug in Max 5 (maxversion() was not properly setting bit 0×4000 when running in a standalone). This will be fixed for Max 5.0.6.

Cheers,
Rob

#148262

You must be logged in to reply to this topic.