"external is still configured for two byte alignment" ? 64 bit conversion of ext

MaxMSPadvanced
dan b's icon

dan b

Hi, I wonder if someone can help with this.
I've been learning to code in C for about 6 months via coding MAX externals.
I've just started trying to convert a couple of my externals to 64 bit and I've hit this issue. Microsoft visual studio throws a "negative subscript" error, but that leads me to a line in the ext.prefix header :

// if external is still configured for two byte alignment this will cause a compile error
// in which case you should change the structure alignment to the compiler default
C74_STATIC_ASSERT( (calcoffset(t_testpackingstruct, secondmember) - calcoffset(t_testpackingstruct, firstmember)) > 2, "struct alignment must be set to default!" );

Reading around this I gather this may be an issue with how I lay out my structs - 64bit processors want double and long variables aligning on 8byte variables, so I reorganised my struct (only one in the external) in order of descending size of data types. Having done this, I still get the issue. I can't see what else might be causing the problem. Any thoughts?
Possibly I'm barking up the wrong tree? Could this be a visual studio config thing rather than a code thing?

dan b's icon

dan b

Hah! Good spot on the inappropriate t_int64s. That's me just lazily skimming the API.

Unfortunately turns out not the issue - nor the t_ints * sitting before the t_ints in the struct (and I think actually a pointer is bigger than a t_int, smaller than a t_double on x64?)

Polynomial sawtooth links look great - I had thought about saws. If you ignore aliasing and variable shape, it's a pretty straightforward change to my current code - just substitute a wrapping function for the folding function. But then the aliasing would be horrendous. Given the jagged wave patterns this kicks out, and the high frequencies the individual voices can head towards when the bounds get small, audio from this is aliased to hell. Improving that is on my todo list. I thought about adding a kind of magnetic repulsion between the balls, which ought to take care of some of the higher harmonics, and might be interesting otherwise.

I really like Peter B's stuff - just a very different approach from either following classical synthesis models, representing a physical system, or trying to produce specific spectral results. Makes me think of Xenakis' approach, weirdly - letting himself follow an internal logic some distance before considering the musicality of the results - then of course making "musical" adaptations and jumping back and forth between the two ways of thinking.
Anyway, once this is working on 64 I'll mail him a link.

I've a few sketches to extend the bounds and bounce idea in other directions, but we'll see how they go. They'll go up on GitHub as they come along.

dan b's icon

dan b

For anyone else hitting similar issues, this was a VS setup thing:

https://msdn.microsoft.com/en-us/library/xh3e3fd0.aspx
I changed code generation > Struct member alignment to 4byte.

Left me with another issue fatal errorLNK1181: cannot open input file 'kernel32.lib'
but nowt to do with max msp, so I won't bother peole here with that...

dan b's icon

dan b

All working now - VS setup issues all the way. Killed my vs project and started again

Raja -thanks for your help here.
Because you showed interest, finished working code is at github now, and if you let me know your mail I can send compiled external with help patch (windows only at the mo I'm afraid - I've not got access to a mac).

dan b's icon

dan b

It's a very clever solution, and I don't think it'd be too hard to adapt my code to use it - just a matter of adapting from the static -1...1 bounds of the classic triangle. Next on the improvements list...

dan b's icon

dan b

Cheers for that. I think I tried to free memory in the order I requested it to help myself keep track of what I'd created vs freed - but as you point out that really won't work for 2d arrays! Weirdly that doesn't cause a problem for any version of Max for Win. I'll correct it on my code.
Glad it's an easy cross compile. Thanks for looking at it.

You've also made me realise that I didn't include my help file in the git directory which I should. I'll have a look if I can incorporate anything from yours. Cheers.

There are a few other issues fixed since I last posted. Biggest one was with how I was (not) handling the effect of "head on" bounces on the lower numbered voice - I can't remember if that fix was before or after last sync to GitHub so you may still see that issue.

I've added variable symmetry since the last Git sync and now in the process of adding ptr. For PTR I'm still wondering whether because in this case the triangles are asymmetric within their cycle vertically as well as horizontally - which I'd expect to change the shape of the polynomial that approximates the linear waveform - that would require an adaptation of PTR(?). Possibly not enough to matter (?)
In any case, the algorithm can be applied as is, so for the mo' I'm cracking on with that.

Anyway, blah.

Will sync changes to GitHub periodically as I make them.