Which programming language(s) were used?

As NS2 runs on iPad, iPhone, Mac and Windows, I am quite curious about which languages were used.

Those seem to be a good choice for programming on multiple platforms.

Any insight? :)

Comments

  • Mostly written in C++ and some assembler for super critical path/optimization parts. I think he had to resort to Obective-C to deal with a few bits of interfacing with Apple APIs but don't quote me on that.

  • @Will said:
    Mostly written in C++ and some assembler for super critical path/optimization parts. I think he had to resort to Obective-C to deal with a few bits of interfacing with Apple APIs but don't quote me on that.

    Many thanks, I think I read about those two languages more than one time in regards to programming for iOS (and other platforms).
    I already know C++ and will have a look at Objective C.

    Biggest problem will be, that I am based on Windows 10 and don't have a Mac.

  • Yeah as it's a 6 years project, I guess they didn't have the time to move to Swift.

  • @Nyanko said:
    Yeah as it's a 6 years project, I guess they didn't have the time to move to Swift.

    I did not hear / read good things about Swift.
    Objective C seems to still be the better solution.
    But I don't know either.

  • edited December 2018

    @tja said:

    @Nyanko said:
    Yeah as it's a 6 years project, I guess they didn't have the time to move to Swift.

    I did not hear / read good things about Swift.
    Objective C seems to still be the better solution.
    But I don't know either.

    There is nothing good or bad to hear about it really. If you use typescript or javascript as a developer, swift is better to use cause it's faster to program and it doesn't have the message passing grammar Objective-C has. But in the end, the compiler gives exactly the same data to the machine. So performance wise, it doesn't change anything.

  • @Nyanko said:

    @tja said:

    @Nyanko said:
    Yeah as it's a 6 years project, I guess they didn't have the time to move to Swift.

    I did not hear / read good things about Swift.
    Objective C seems to still be the better solution.
    But I don't know either.

    There is nothing good or bad to hear about it really. If you use typescript or javascript as a developer, swift is better to use cause it's faster to program and it doesn't have the message passing grammar Objective-C has. But in the end, the compiler gives exactly the same data to the machine. So performance wise, it doesn't change anything.

    Ah, that's new and interesting.
    I only ever did C, C++ and Python.

  • @tja said:

    @Nyanko said:

    @tja said:

    @Nyanko said:
    Yeah as it's a 6 years project, I guess they didn't have the time to move to Swift.

    I did not hear / read good things about Swift.
    Objective C seems to still be the better solution.
    But I don't know either.

    There is nothing good or bad to hear about it really. If you use typescript or javascript as a developer, swift is better to use cause it's faster to program and it doesn't have the message passing grammar Objective-C has. But in the end, the compiler gives exactly the same data to the machine. So performance wise, it doesn't change anything.

    Ah, that's new and interesting.
    I only ever did C, C++ and Python.

    Old school then? Sounds good. I've been into angular for a few years now, so typescript is what I use everyday. And when I look at swift coding, it talks to me naturally. I need to get into it closer though, cause so far I have only used Ojective-C when I was making ios apps years ago. Swift looks interesting and fast.

  • edited December 2018

    @Nyanko
    So performance wise, it doesn't change anything.

    It does change everything believe me :-) In C++ you have a dramatically lot more space for CPU optimalisation and for make rock solid stable apps (at the end, look at NS :)) I bet most stable and CPU efficient apps have core coded in C++ / ASM.

    Actually also Michael from AudioBus wrote some article why is it CRUCIAL to use C++ for creating audio apps. Cannot found it for now, probably it was on some his blog or personal website ??

    Also @alexbuga can tell you something about this topic (author of Samplist app), i think he mentioned tha he struggles with rewriting his app from Swift to C++ because of wihout it is is impossible (or at least very complicated) to release it as AUv3 plugin .. (@alexbuga sorry if i misinterpret something :))

  • @Nyanko said:
    So performance wise, it doesn't change anything.

    Very, very wrong.

  • tjatja
    edited December 2018

    I think, we have some misunderstanding or misreading above.

    It was written, that Objective C and Swift are quite the same performance wise, not Objective C and C++ (or Swift and C++).

    Better?

  • edited December 2018

    There are still problems with Swift and the CoreAudio/AUv3 framework. I would recommend sticking to C++ for realtime audio/dsp and ObjC for UI/audio framework stuff.

  • @brambos said:
    There are still problems with Swift and the CoreAudio/AUv3 framework. I would recommend sticking to C++ for audio and ObjC for UI/audio framework stuff.

    Ah, great. I seem to have read something like that before, but was not sure.
    Thanks :)

  • edited December 2018

    @tja said:
    Biggest problem will be, that I am based on Windows 10 and don't have a Mac.

    One possible entry point for you might be JUCE. You can develop on Windows in a cross-platform manner. You’ll still need to find a way to actually compile and publish to iOS, but you can get a long way in learning and development on the PC before needing to cross that bridge.

    I’m sure it’s not the most optimized thing in the world, but it has been used for Gadget and BeatHawk development, so it can’t be all bad. On the other hand FL Studio Mobile is developed in it ... so maybe it can be.

    Anyway, it’s free, until you start selling enough to need to license it.

  • I'm guessing it's about 95% C++ (with assembler for the DSP), and Objective C just used where there's no other choice. I always immediately wrap Objective C in a C++ interface in case Apple go and screw me over one day by changing everything.

    As Michael and Bram say, you can't use Objective C or Swift for audio as they're not hard real-time, but even if that weren't the case they're Apple specific, so every line of code you write in those languages will never work on anything else and is subject to Apple's whim.

    But I mainly find it faster to develop using a Windows build as I get tools such as Visual Studio's Edit and Continue (which saves masses of time for quick tweaks while the code's running) and a much better debugger (which saves masses of time when the code's not working).

  • tjatja
    edited December 2018

    @number37 said:

    @tja said:
    Biggest problem will be, that I am based on Windows 10 and don't have a Mac.

    One possible entry point for you might be JUCE. You can develop on Windows in a cross-platform manner. You’ll still need to find a way to actually compile and publish to iOS, but you can get a long way in learning and development on the PC before needing to cross that bridge.

    Many thanks, I found https://juce.com and will have a look at it.
    But as you said, compiling to iOS will be the greatest problem.

  • @Blip Interactive said:
    But I mainly find it faster to develop using a Windows build as I get tools such as Visual Studio's Edit and Continue (which saves masses of time for quick tweaks while the code's running) and a much better debugger (which saves masses of time when the code's not working).

    Developing on Windows and then only later compile to iOS would even better fit my possibilities :)

    Did you use any C++ framework or existing libraries?

    Thanks for the information!

  • I used a commercially licensed version of JUCE which is now about 6 years old and I've heavily modified it over time. I really just use its core stuff (eg. strings, file handling etc.) as I just can't get on with stl. You can do lots of stuff with stl and it's extremely extensible, but the JUCE equivalents are much easier to understand for most common 'real world' tasks. Plus a typo doesn't results in a million lines of template related gobbledygook from the compiler!

  • edited December 2018

    Ahh, no wonder there is a below the radar Windows version. ;)

  • Yes, the Windows version's more an accident of the development rather than a fully fledged product!

Sign In or Register to comment.