Nano for Surface?
Been too long without a mom joke around here. Thanks for that.
Couldn't resist :)
' NanoStudio will actually run on 6 platforms at the moment (iOS, OS X, Windows, Android, PlayBook, Windows RT) yet iOS is STILL looking like the only viable mobile platform, all due to audio latency.'
If it works already, please port it to Playbook! The latency's not too bad on Playbook actually (at least not using Caustic) but that doesn't really concern me too much at the moment. It would be great even to use it just as a playback device for gigging. The bigger screen would just make operating it live easier than on my iPod Touch. Just being able to import .NSP files and play them back would be worth the asking price alone but it would still be possible to use all the non realtime features like synth editing and mixing, sequence editing and live sampling.
At £129 for a 64GB Playbook now it would make a viable alternative for many people to an iPad. Any realtime recording could be done with the Windows version (assuming the use of a cheap PC) or on an inexpensive iPod Touch.
I guess the same applies to Android tablet owners.
I agree with Pablo. While I find it very admirable that you are such a perfectionist. Android has really improved alot over the years, but the marketplace is still desperately lacking in good music creation apps. Please...on behalf of all android users that feel the same way as I do. Just release whatever you have currently working. We will pay the asking price. You can update later whenever you want. Just give us some decent music production tools! Think of the increase in revenue just from the android marketplace alone! Just being able to arrange and edit samples is more then worth it in my opinion. Fl Studios seems to have been struggling with the same audio latency issues as well, but they have had some significant breakthroughs and our hoping to release their app for android very soon. Their has to be a way.
Thank you for differentiating between Windows 8 and Windows RT since programs that work on one will NOT work on the other. Most people making comments don't appear to realize this. Are you saying you have Nano Studio in the works for both platforms? Low latency Nano for Surface RT would make me very happy.
From reading the posts on MSDN it does not look promising unless there is more going on behind the scenes. It seems they only designed it to support a minimum of 100ms to allow VOIP which is good enough for them. Strange that they got Jordon Rudess to play and demo his Surface app at one of the developer conferences, it looked like they were challenging Apple at the time.
Yes, quite honestly the figure of 100ms pissed me off after all the work I'd put in.
I am selling my iPad today and replaced it with a Surface RT. Nanostudio has got to be the best music app for the iPad and I REALLY want to see it ported over if possible. Obviously corner don't need to be cut, and I see that was stated. Just take this as a bit of encouragement ;).
"Realtime Playing is not important"
Don't give up on Surface RT. It has gotten a lot of bad press by folks who really don't understand the device at all or who are in love with their IPADs and don't think anything else can compete. Of course it doesn't run full blown windows programs but Ipads don't run apple programs either - whoever thought it would? Its app selection is a weak point at this time but the store is experiencing tremendous growth, but one thing folks don't understand is internet explorer is not some scaled down browser - it is fully capable and has no limitations as opposed to the simple iPad browser. Quite honestly under the hood the Surface RT is a very capable device compared to an IPAD and there is a lot of development going on over at XDA forums. With the jailbreak already released it is very easy to port over to RT from regular windows third party apps but due to needing source code it has been limited at this point to open source. Audacity is already ported over as well as a number of popular open source programs.
Also just for kicks I plugged in a cheap USB guitar interface to my surface RT and windows immediately recognized it with its generic driver. Playing my guitar through it the latency did not sound to bad but because there are no apps for guitar effects at this time, there was not much I could do with it.
As a guitarist I see how apple owns the market for music production but quite honestly I am hearing a lot about how people are sick of the limitations of their ipads in other areas, and MS is not going to go down without a fight. From a development standpoint if an app is developed for Win8 it can be compiled for RT as well and let's face it Win8 is not going to disappear. It will grow even if it is by new computer installs alone.
I don't want to give up on it. I have a Surface RT sitting on my desk, I set up in a new Windows 8 PC to develop for it, and I spent a fair amount of time in getting NS running on it - but the latency's poor so my hands are tied.
The only benefit right now is that optimizing ARM code is now a lot easier for me because I can run it on the Surface using Microsoft's superb and professional development environment rather than the mess that is Apple's Xcode :)
Here's a little picture of it running on the Surface RT, along with the PlayBook too:
I must say that it looks lovely especially on that big screen.... But I can just imagine that while a few people *may* be happy with the current latency, I can also imagine the inevitable shit and flame storm that would ensue from all those expecting a product on such a platform to have latency on a par with the iOS devices. For that very reason alone I can see why Matt would be reluctant to support it.
Microsoft basically just need to get their act together. I've already been reading elsewhere that many big names such as Samsung and Asus think that Windows 8 is simply 'another Vista'. Maybe they'll sort it by W9? Since I'm currently looking to switch from Mac to Windows, I'd certainly be interested *IF* MS can sort it out. But until then, I'm okay with this (old) Mac, and my iPad.
Yeah Visual Studio rocks :)
Matt, if it is not a secret, which tools/frameworks did you use to develop NanoStudio? The fact that it runs perfectly on multiple platforms is amusing.
I don't really use many existing frameworks - just OpenGL for rendering and a couple of open source libraries for zip and ogg compression (although Windows RT doesn't have OpenGL so I had to write a DirectX renderer too). My experience with existing frameworks is that you often evaluate them quickly and they seem OK, and then a month down the line when you're starting to really use them seriously you start running up against limitations and/or other peoples' bugs. Once you hit that stage, you then have to starting delving into and attempting to understand reams of stuff written by someone else, everything slows to a crawl, and you wish you'd just done it yourself in the first place. So these days I just cut out that process and just write it myself - at least that way, it's normally guaranteed to run on all the platforms I have in mind, I fully understand the limitations and no big surprises come along.
I try to do 80% of the development on the PC because the hardware's so much faster and Microsoft's Visual Studio is excellent - the Android and BlackBerry dev environments feel decidedly homebrew (Eclipse - bleuurgh!) and Xcode's normal reply to most things is 'Insufficient data, does not compute, shall I crash now?'. By comparison, Visual Studio serves me my favourite tea and biscuits at 11am sharp, allows me to make code changes while the app's still running and is quite happy to get together with me during a quiet period to generally taunt and throw bricks in the general direction of Xcode . This means that I can't use Objective-C unless it's completely necessary (it's Apple's proprietary language) but that suits me fine 'cos it's totally unnecessary and yucky and Apple like to change it now and again, seemingly just to keep developers on their toes.
I did spend a couple of weeks earlier this year evaluating a library/framework called JUCE. It's very full featured and written well, but its UI rendering was too slow and the other functionality I now have reasonably covered - it I'd known about it when I first started NanoStudio though, I could well be using it (or parts of it) now.
Thank you very much for the comprehensive answer, Matt.
Rendering 2D UI in OpenGL is certainly unusual.
If it is not too hard, could you change my forum ID to "ozmoroz"? I mistyped it when I registered and there seem to be no way to change it.
iOS does have Core Graphics or whatever it's called, but it's really slow and not cross platform. I used to work on games so maybe using OpenGL feels kind of natural to me!
Since you are able to use Visual Studio to write for iOS, does that mean that NanoStudio is built in Mono?
If not, could you give me a clue? :-)
You begin by trying to work out what each platform does differently - generally this includes opening the main window, key/mouse/touch input, MIDI, audio, anything that needs to be done in a non C/C++ language (such as Obj-C or Java) etc. Next, you write a low level layer for each platform. The purpose of the low level layer is to wrap up all the platform-specific gubbins at the bottom end, and then present a unified C++ interface at its top end. After that, you then write the application in straight C++ on top of the low level layer. So when the application starts up, it asks the low level layer to (for example) open a window. The low level layer then does what needs to be done to open a window on that platform and (hopefully) comes back to report that it did it. That way, the application (usually) doesn't need to worry about any of the platform-specific stuff.
JUCE is the library that have been made for developping the well known Tracktion DAW.
I don't understand why you say it's UI rendering is too slow. Well, if you have worked on games, I understand, but an application like Nanostudio has no big needs in this area.
I think JUCE is a good choice if someone wants to create cross-platform applications.
Now, you have your own framework, and it's good because you have more control on everything.
I tried in the past to write music applications and VST (see my PQN Audio site ) but I'm too lazy and I gave up.
So I can say that I admire you because you have done an amazing work with Nanostudio.
JUCE uses a software renderer, which is flexible and gives the same behaviour across all platforms but it means that the main CPU can be tied up drawing every single pixel. On mobile devices with retina displays, that's a shitload of pixels! Admittedly it only does this when an area of the screen needs to change, and it has an OpenGL accelerated option, but in my tests simple scenes would take several milliseconds (or even >10ms) to redraw and animations got choppy at times. On the iPhone, it sometimes had trouble maintaining 60Hz and their forum has lots of comments about Android performance too.
Equivalent scenes using my own renderer were well under a millisecond for the main CPU, and I normally redraw the entire screen every frame rather than just refreshing the changed areas - better to keep the GPU busy rasterizing polygons (that's its job!) and spend that CPU time on audio. JUCE seems to have this (to me anyway) slightly odd set up where the OpenGL rendering takes place on a different thread - I'm not sure if the timing indeterminism of this was causing the animation choppiness, but after a couple of weeks I found myself getting into the whole 'delving into someone else's code' syndrome, and the purpose of the evaluation was to avoid precisely that! It feels like the OpenGL acceleration was shoehorned into the software renderer API, but to take full advantage of the GPU you really need a paradigm shift where you just push geometry in one direction and carefully consider GPU stalls - I'm not sure it's doing that.
Don't get me wrong, I thought JUCE was a very well written library (and all by one guy too), but the renderer (and the quality of its font rendering) is probably its weakest area. As I said, if I'd known about it when I started NanoStudio I would have probably used the audio side of it and maybe added my own renderer.
I just took a look at your website - if I ever get a golf cart, I'm going to get some badass speakers from you :)
And you can bump the sounds of my new band 'timing indeterminism' in that cart.
I the 'The Temporal Indeterminists' would have more bite.
Oh I see. Damn, I was hoping for mate's rates on the golf cart sound system :)
Oki doki, so with all that time spent on Win 8 development, I guess there is not a chance for NS to jump on the (Audio) BUS or Jack for that matter any time soon...
Come on cheer up atlatnessiti, you always seem a little down, I do worry about you :)
I am a little bit down, but that is because of NO development progress for iOS NS...
The truth is that I've got loads on at the moment and I'm not sure when I'll be able to fit anything in, but I know it's a popular request.
It'd probably help a bit if you could describe how you'd like to use NanoStudio with Audiobus. Adding MIDI out/clock sync would probably involve too many changes right now, but adding an Audiobus output from NanoStudio or an Audiobus input to NanoStudio might be in with a chance at some point. So this might enable these scenarios:
1 - External app drives NanoStudio via MIDI, NanoStudio outputs to Audiobus
2 - NanoStudio uses an Audiobus input for sampling
3 - NanoStudio brings in an Audiobus input and makes it available as an additional input mixer channel
3 sounds awful fun but without midi sync, I can't see a real use for it. Unless there were audiobus sends on the mixer and that could be a return. :) Lord, I'm chubbed just typing that.
1&2... Yes, please!