trying to compile, only 2 errors left !

    Jun 07 2014 | 12:10 am
    First and beforehand, i know that there are plenty wrong things in that code. It comes from PureData, the fdn~ external, and i butchered it to ensure, in a first time, there would be only the big errors left. I didn't do the outlets/inlets translation rightly so far, i may have borked things when i replaced all t_int with int...
    The wort thing apparently seems related to the use of a nested function. Nested functions are not part of c standard, but allowed by most gcc compilers. Apple disabled it by default, it is possible to re enable it by adding a -fnested-functions in the "other C flags" field of the project build infos. Thus, the "Nested functions are disabled" error message went away.
    But there are still 2 errors left, at the same line as where that nested function thing was giving trouble (line 475) :
    error: expected '=', ',', ';', 'asm' or '__attribute__' before '->' token
    error: expected expression before '->' token
    I attached the bugging source in case anyone would feel like giving it an eye. Thanks in advance !

    • Jun 07 2014 | 12:11 am
      haahhaaaaaaaaahhahaa "this file type is not permitted for security reasons" LOL is this a developper's forum ?...
      i zipped it :
    • Jun 07 2014 | 10:34 pm
      I spy with my little eye…
      In line 472 you've got the keyword 'float' hanging around with nothing attached to it and no semicolon. So, it looks like the first 'x' in line 474 is being treated as part of a variable declaration, at which point the '->' token won't parse (although one any of the tokens the compiler enumerates would, conceivably, parse. If the compiler doesn't complain until line 475, well, compilers do that sometimes.
      No guarantees, but I'd ^W the float.
      HtH -- P
    • Jun 07 2014 | 11:58 pm
      Thanks a lot ! What an eye !...
      I straightforward removed that floating "float" and now, just 1 error ... it is as follows :
      "_IS_DENORMAL", referenced from:
            _fdn_perform in fdn~.o
      ld: symbol(s) not found
      collect2: ld returned 1 exit status
      apparently it happens during the linking stage.
      maybe it is time that i go back to the original source and do correct things ?..
    • Jun 09 2014 | 12:50 am
      if that's your only remaining error(who knows what other errors it might uncover when fixed, though :D)... you can also try commenting out the line in the original fdn.c file:
      change save = IS_DENORMAL(save) ? 0 : save; to //save = IS_DENORMAL(save) ? 0 : save;... or erase it altogether, then try to recompile.
      (alternately, going through gen~-exported code, a fixdenorm is defined in the 'genlib_ops.h':
      // assumes v is a 64-bit double:
      #define GENLIB_IS_NAN_DOUBLE(v)			(((((uint32_t *)&(v))[1])&0x7fe00000)==0x7fe00000) 
      #define GENLIB_FIX_NAN_DOUBLE(v)		((v)=GENLIB_IS_NAN_DOUBLE(v)?0.:(v))
      	#define GENLIB_IS_DENORM_DOUBLE(v)	(v)
      	#define GENLIB_FIX_DENORM_DOUBLE(v)	(v)
      	#define GENLIB_IS_DENORM_DOUBLE(v)	((((((uint32_t *)&(v))[1])&0x7fe00000)==0)&&((v)!=0.))
      	#define GENLIB_FIX_DENORM_DOUBLE(v)	((v)=GENLIB_IS_DENORM_DOUBLE(v)?0.f:(v))
      and maybe you could implement something similar in a header file for c compilation and then apply the function to the 'save' variable from the line above in the fdn.c file...)
      just ideas :)
    • Jun 09 2014 | 6:52 pm
      Hi Vichug,
      you have the macros IS_DENORM_FLOAT and IS_DENORM_DOUBLE defined in z_sampletype.h
      Just use the appropriate one in place of IS_DENORMAL.
      As an alternative (and probably better) option you can replace the whole line of code with FIX_DENORM_FLOAT or FIX_DENORM_DOUBLE.
      As you have it right now, the 100% correct way to do it would be the following:
      Also, your external won't work unless you add C74_EXPORT between int and main.
      As a piece of advice, I would perform all calculations in double precision.
      Let me know if it all compiles and works successfully.
      - Luigi
    • Jun 09 2014 | 8:03 pm
      That's a lot of things that i don't understand yet... and i'll need to come back to this in two days or so
      (but basically, it means _IS_DENORMAL was a macro for a function of a Pd library, which doesn't exist in Max right ? if i understood well. and there exists _IS_DENORMAL_FLOAT and _IS_DENORMAL_DOUBLE in Max api ? also the FIX )
      @Luigi : is C74_EXPORT a new thing ?
      Thanks a lot anyway
    • Jun 09 2014 | 9:44 pm
      "(but basically, it means _IS_DENORMAL was a macro for a function of a Pd library, which doesn’t exist in Max right ? if i understood well. and there exists _IS_DENORMAL_FLOAT and _IS_DENORMAL_DOUBLE in Max api ? also the FIX )"
      YES! exactly. you understand. (you probably want the 'double' forms of the functions(not 'float') if you're building for 64-bit max6 and for more precision anyways)
      A denormal is just a very small fractional number close to 0, which can be unnecessarily expensive on CPU especially when output to other things which will further calculate on it. The line in fdn~.c which uses IS_DENORMAL basically determines whether the output is close enough to 0(whether it's a denormal or not), and then if it is, simply replaces it with 0 using this conditional statement: "save = IS_DENORMAL(save) ? 0 : save;"
      in gen~ or in the max library, the 'fixdenorm'(or similarly spelled :p) function does the same exact thing that conditional statement above does. so you could skip determining whether it's a denormal(using 'is_denormal') and instead just use the fixdenorm function similar to what Luigi wrote:
      "save = fixdenorm(save);"
      (^keeping in mind that my code is more like pseudo-code, and you'd want the exact capitalization and spelling of the function from the 'z_sampletype.h' header file for max that luigi mentioned)
      Finally, alternately, i wasn't sure how much you were familiar with this stuff(apologies if i've explained too much!), so i also mentioned(because it might be easier for a beginner) that you can simply delete the line or comment it out entirely, just to get a test version of the object going quickly(if it outputs denormals, it can still perform fine(you could even say the output will be unnecessarily overaccurate), it's just not efficient when used in larger contexts...).
      simply erase the line "save = IS_DENORMAL(save) ? 0 : save;" from fdn~.c entirely just to see if you can compile and get it working first, then you can go back and learn how to include the right header files and use the appropriate functions needed for fixing denormals.
      (But it sounds like you mostly understand everything that needs to be done already from your last post :)
      edit: oh and regarding this, "@Luigi : is C74_EXPORT a new thing ?" i'm interested, too, didn't quite understand that part... i don't remember having to do that with older sdks, but i should look over the max6 one more carefully(my excuse: gen~ is soooo distracting! :D)....
    • Jun 10 2014 | 4:47 am
      Yes, the C74_EXPORT is a "new thing"...
      You need it if you want your external to work in Max 6.
      Please look at the example projects in the latest SDK.
      - Luigi
    • Jun 19 2014 | 11:56 am
      Hey, back on topic : i finally succeeded a compilation ! yay ! and it instantiates without crashing max ! even shows an inlet ! not saying the hting is working though, but that's a first step... now to create signal inlet and outlet and make sure it works...
      Raja, you're assuming right that i'm a total noob when it comes to c and compiling :D and Luigi, on that C74_export thing, i'm still using sdk 6.0.4 which doesn't understand this. Is that necessary since max 64 bits ? I'm not sure i understand what this does do, and why it's necessary all of a sudden if it's not related to that.
    • Jul 21 2014 | 5:51 pm
      C74_EXPORT is orthogonal to 64-bit, but it does make make some project maintenance stuff easier (e.g. on Windows you don't need to create multiple .def files). You should be able to copy it from the newer SDK back to the older SDK if you desire to use it in the older SDK.
    • Sep 01 2014 | 11:34 am
      just updating this dev thread, since i didn't think originally of the proper place to post about my work on the external :p
      finally ported to MSP successfully, see here: