Imitone -- wow! Most embarassing post I ever started

[interactopia]

Tom --

(Happy to answer here, just I can't guarantee I'll keep an eye on the thread as I have a lot of work to do getting the update assembled.)

The VST version is a low priority right now. It's going to take a lot of work to develop, mainly because the entire interface will most likely need to be re-created. Based on my testing, the latency induced by standalone operation is very small -- most of the latency actually comes from imitone's tracking and the new code has improved on that significantly.

I remain aware of the biggest practical problem with standalone operation: its inability to use the same audio streams as the DAW. To that end, a possible compromise could be to create a plug-in which interfaces with the standalone app. This would eliminate any additional latency, allow audio and/or MIDI to be routed as if the software were a VST, and most importantly would not create any conflicts with the DAW over the audio device. It would also be much easier to develop and maintain. The only difference would be that imitone would remain a separate program. (A third option would be to use ReWire, but support for this is more limited than support for VST.)

The standalone app will remain the primary focus of development unless I see significant efforts from DAW-makers toward making MIDI-producing plug-ins more usable. For the time being, I understand it's not even possible to use audio-to-MIDI plug-ins in some major DAWs, and even where it is, the routing makes it far more complex and less convenient than using a virtual controller.


Open to anyone's thoughts regarding the interfaced plug-in.

[TabSel]

Rewire is not an option, as it only streams audio from the client (imitone) to the host (daw)

Inter process audio steaming (interfacing with the standalone) is quite complex.

However, I sure hope it gains priority soon!!! It just takes way too long, after your promises during the kickstarter campain.

[ThomasHelzle]

Tom --

(Happy to answer here, just I can't guarantee I'll keep an eye on the thread as I have a lot of work to do getting the update assembled.)

The VST version is a low priority right now. It's going to take a lot of work to develop, mainly because the entire interface will most likely need to be re-created. Based on my testing, the latency induced by standalone operation is very small -- most of the latency actually comes from imitone's tracking and the new code has improved on that significantly.

I remain aware of the biggest practical problem with standalone operation: its inability to use the same audio streams as the DAW. To that end, a possible compromise could be to create a plug-in which interfaces with the standalone app. This would eliminate any additional latency, allow audio and/or MIDI to be routed as if the software were a VST, and most importantly would not create any conflicts with the DAW over the audio device. It would also be much easier to develop and maintain. The only difference would be that imitone would remain a separate program. (A third option would be to use ReWire, but support for this is more limited than support for VST.)

The standalone app will remain the primary focus of development unless I see significant efforts from DAW-makers toward making MIDI-producing plug-ins more usable. For the time being, I understand it's not even possible to use audio-to-MIDI plug-ins in some major DAWs, and even where it is, the routing makes it far more complex and less convenient than using a virtual controller.


Open to anyone's thoughts regarding the interfaced plug-in.

Thanks Evan,

well, I happily disagree here
Can't speak for the GUI since I don't know how you set it up, but using a framework like JUCE should make it doable.

Almost every DAW allows for Midi-routing. Many need the Midi generating VST to reside in a separate track, but from there it's usually pretty simple to route the Midi data.
My personal favourite DAW, Bitwig Studio has no problem using any VST in any order and combination on a single track, so it would be not an issue at all. It even has hybrid Midi/Audio tracks.
This would also allow to send audio from a track to Imitone and have the Midi output on the same track...
Midi generating plugins like Midi Guitar and Midi Bass from JamOrigin work like this and also offer to let the audio through for further mangling. No problem at all.
I use such tools all the time (not only in BWS).

Your workaround with another plugin that interfaces with the standalone sounds like an overdeveloped nightmare to me.
Not only technically, but also from a workflow standpoint. I'd much prefer to have everything inside one project file than having to remember how I did set up the system the last time with external tools, midi routing etc. As a VST, I would open my file and everything would be as the last time I used it.
I guess most professional users would prefer it that way as well.

And finally: In your Kickstarter, the VST version was a reached goal and it was projected to be available quite a while ago, so your view leaves me a bit baffled. I understand that you have no experience with VSTs, but the KVR developer forum would certainly be willing and able to help you with the questions you may have, a lot of knowledgeable people are around there.
If some DAWs have suboptimal Midi plugin support isn't something that invalidates that many other DAWs handle it quite well.

Again, for me personally, the VST version is the only version that makes sense for professional use, zero configuration needed, fully restorable setup and no need to fiddle with another GUI behind your DAW.

Cheers,

Tom

[interactopia]

Hey, Tom --

Barring sandboxing issues, an interfaced VST could potentially boot the standalone and restore any settings associated with the project. Again, the practical difference would be that imitone ran as a separate application. This is just an idea, but it's a way I could have a working imitone VST available much, much sooner. The alternative would be to build a version of imitone with a minimal UI, and given how much the displays can aid in live usage, I'm not keen on that.

Regarding VST usability, it really varies from tool to tool because different DAWs handle routing in such diverse ways. My main concern there is that routing is usually outside the abilities of a beginning user. During a conversation with the Cakewalk developers, I learned that their software doesn't support audio-to-MIDI VSTs, and because they're such an exotic category I expect other DAWs have this issue as well.

Regarding dates: The May date specified in my Kickstarter referred to the availability of a beta version -- and I fulfilled that. None of the stretch goals came with specified dates, and I stated in an update that with the exception of automatic scale detection, they would follow the completion of the standalone app. I did overzealously estimate December for an iOS release, and will accept blame for that.

In any case, I won't be putting out a version 1.0 until the software meets a high standard of quality.

[interactopia]

(ignore this post -- mistook the quote button for the edit button)

[ThomasHelzle]

Hey, Tom --

Barring sandboxing issues, an interfaced VST could potentially boot the standalone and restore any settings associated with the project. Again, the practical difference would be that imitone ran as a separate application. This is just an idea, but it's a way I could have a working imitone VST available much, much sooner. The alternative would be to build a version of imitone with a minimal UI, and given how much the displays can aid in live usage, I'm not keen on that.

Regarding VST usability, it really varies from tool to tool because different DAWs handle routing in such diverse ways. My main concern there is that routing is usually outside the abilities of a beginning user. During a conversation with the Cakewalk developers, I learned that their software doesn't support audio-to-MIDI VSTs, and because they're such an exotic category I expect other DAWs have this issue as well.

Regarding dates: The May date specified in my Kickstarter referred to the availability of a beta version -- and I fulfilled that. None of the stretch goals came with specified dates, and I stated in an update that with the exception of automatic scale detection, they would follow the completion of the standalone app. I did overzealously estimate December for an iOS release, and will accept blame for that.

I'll keep working on this software until it's finished. I have no intention of putting out a half-baked v1.0, even if it's the best in the world.

Okay, so the question for me would be: can you have a GUI-less VST that integrates the standalone so completely that it behaves for all intent and purposes like a fully integrated VST? So that people wanting to have audio and midi fully integrated can use it as if it would be one VST?
In that case I'd be fine.

But one impression I get from your communication is, that you somehow are - like was assumed in this thread before - a procrastinator. You seem to overthink the whole thing too much. In the time you worry, you could probably have a first VST version finished. Of course it's work, of course there will be stumbling blocks, but the sooner you start, the sooner you'll know. And I mean really know, not just "assume" or "think" or get some medium valid opinion from somebody else.
And I don't see why you on one side worry about beginners having problems with routing Midi in their DAW while on the other hand the current system with the external standalone is five times as complicated?
It all looks like self invented pseudo problems to me.

This is the JamOrigin DAW setup guide with explanations for all major DAWs, including Sonar:
http://jamorigin.com/docs/midi-guitar-f ... up-guides/
Yes, some DAWs don't support VSTs or this kind of routing, but for that there is the standalone.

I use this kind of stuff for ages.
This is basically how all PIZMIDI plugins work, how I usually use Audio Damage Axon, SugarByte Thesys, heck, even Rayzoon Jamstix (a drum plugin) can be set to only output Midi, which I often use.
And the JamOrigin Bass and Guitar to Midi plugins do exactly the same as Imitone, only for Bass and Guitar. Of course they have standalone versions too, but that is the users choice to make, depending on DAW and taste.
There are hundreds of arpeggiators, sequencers, rhythmic modules of all kinds, so you can simply assume that people who are interested in this kind of stuff will know (or find out) how to use them (and use a DAW that supports it).

I'm sorry to say this, but your "assuming that other DAWs have the same issue as Sonar" (which it actually does NOT have) is silly. I can assure you that most DAWs on the market DON'T have this issue and while the routing may not be optimal or fully straight forward, it's totally doable in most.

I would really recommend to get into contact with people who do or did this kind of thing already and see if some exchange of knowledge can be arranged.
And just start doing it instead of thinking it to death...

Best of luck.

Cheers,

Tom

[pottering]

I bought Imitone some months ago, to me personally a VST version would much more useful than any standalone version, even with an minimal UI.

And it would be useful even with a "non-perfect" detection algo, as I'm not after perfect transcriptions/performances, but rather an alternative way to "sketch" some rhythms and melodies into my DAW, from some singing or beatboxing (or maybe even sounds from "finger-drumming" in a wooden table?).

So if you can release even an "imperfect" VST version, it would great.

I consider myself a beginner, but I can handle routing MIDI inside a DAW just fine.

[interactopia]

Pottering -- everything you mention is already possible; imitone can already be used with any MIDI-compatible DAW for Windows or OS X.

I worry I haven't been clear about what I'm developing: A MIDI controller. If a hardware vendor put out a MIDI keyboard whose input could be captured by way of a VST plug-in, that method would be burdensome and impractical for a majority of users. DAWs have separate, simplified routing for controller inputs (recording / monitoring buttons), and I'm concerned with supporting that workflow as well as I can.

The strengths of the standalone controller are thus:

1. Easier to set up and use with any DAW, in the general case. (Instant, in some cases.)
2. imitone's visual aids may be viewed regardless of the UI state of the DAW.

As to why I should develop a VST unit, I see two clear reasons, the second thanks to Thomas' input:

1. No contention between imitone and the DAW over the input device.
2. Allows imitone's settings to be saved and restored with a project.

My ears are open to any counterpoints; they could prove very helpful in making my software better.

Regarding the interfaced plug-in: The main difference for practical purposes would be that the imitone window wouldn't be a child of the DAW. It could be minimized, moved or top-pinned freely. I see this as a strength: The tuner display can be very helpful. That said, I've done a bit more research and the prospects for hardware rendering in VST interfaces are better than I had thought.

The reason I'm not developing the VST now is that I plan on fulfilling most stretch goals (with the exception of automatic scale detection) after releasing version 1.0 of the software. I don't think it's good practice to let stretch goals delay fulfillment. That said, I can see I didn't clarify that schedule in my campaign and I will accept criticism for that.

Regarding my remark about Cakewalk, that was based on a conversation with one of their developers. He may have been talking about Music Creator, which I'm also concerned about supporting.

[ThomasHelzle]

Of course the standalone version makes sense for people who either want it that way or use a DAW that does not support the integrated workflow. That isn't in question IMO.
But I'm sure everybody else (= most pro users) would much prefer a fully integrated VST.

- You don't develop a midi controller IMO. It is audio to midi software. So other than an external hardware unit your software runs on the same computer in most cases. This changes the situation and makes the standalone approach quite bothersome actually in my experience and view. Imagine somebody working with several applications like yours: He would have to fiddle around with multiple LoopMidi connections, would have problems with ASIO inputs and whatnot. Your installer actually killed my nicely working LoopMidi setup... Multiply that with 10... It is NOT the same as a keyboard.
As VST, it would integrate nicely with the typical working environment every musician is working with anyway and even with several in the same project he would be just fine. That is the whole idea behind VST, having the tools fully integrated in your DAW.
"Easier to setup" is not the case for me with the standalone.

- While working with your DAW, you can have the VST window visible just as well, put it on a second monitor, minimize or even close it or whatever you like. I don't see why having it as a separate application should be favourable. VST windows are always shown on top of the DAW so no need to make it stay-on-top.
I don't see this as a valid argument. It's already solved and works just fine for pretty much everybody.

- There are tons of amazing VST GUIs out there, hardware accelerated and not, there are even VSTs that use the GPU for audio calculations. Again, IMO this is basically a field of knowledge that needs to be investigated and learned, not an argument for or against a VST version.

- I can't comment on your plans and how you try to reach the goals, but I strongly feel that developing the VST in parallel would have been a much more productive and practical approach than always moving it towards the horizon.
I hope I live to see the VST... I would not have expected that after almost 1.5 years there wouldn't even be a VST beta and the dev talking about it being low priority...

I didn't buy Imitone for my grandchildren

Best of luck!

Cheers,

Tom

[TabSel]

Thanks Tom, couldn't agree more.

I'm going so far to say it's pretty inadequate to discuss the pros and cons of a VST. The VST spec is pretty clear: it accepts audio and midi I/O. However any user routes audio and midi isn't up to Evan tasks. HIS task is to develop a VST that does audio IN and midi out. Finished.
That was promised and part of the Kickstarter campaign.

Now even the algo seems to be still unfinished.

It's about time to deliver. a VST beta is overdue. However Evan technically implements the VST spec, it's up to him. Doing ipc with the standalone or a self contained dll.

(Considering that the ipc method is like building a VST architecture bridge that most professional developers are struggling with regarding general stability even with their own single daw I strongly advise Evan to sit down and begin restructuring UI code in order to build a self contained VST dll! Now! Lamenting won't get him anywhere. It's boring work, but is has to be done in order to deliver the stretch goals I put my money in in good hope, which I'm about to lose)

Wether it makes sense to him or not. The VST is one of his stretch goals. I once asked him if he ever did a VST before and he didn't. Concerning the struggles professionals are faced with regarding compatibility with major DAWs, my guess is that a VST won't hit the store the next two years or so, even when work starts now.

So please Evan, do tell: what is your erstimated time frame form delivering your stretch goals! Have you even started to do a VST conforming prototype framework for your algo?

I doubt it will be delivered. I not only invested in your 0.5 standalone beta. I invested in a imitone VST, too.

Will this be delivered?

[Uncle E]

Evan, first of all, thank you for providing me with a refund. I appreciate that.

As to why I should develop a VST unit, I see two clear reasons, the second thanks to Thomas' input:

1. No contention between imitone and the DAW over the input device.
2. Allows imitone's settings to be saved and restored with a project.

As a software retailer, I can tell you that a VST version will sell much better than a standalone version.

The reason I'm not developing the VST now is that I plan on fulfilling most stretch goals (with the exception of automatic scale detection) after releasing version 1.0 of the software. I don't think it's good practice to let stretch goals delay fulfillment.

This makes sense. As someone who doesn't have a lot of experience with Kickstarter, I didn't make a distinction between the main goal and the stretch goals but I see now where you're coming from. It might be worth clarifying this to others like me because I'm certain a large portion of your funders are counting on the VST version.

I do hope you do well. It's a great project and I'm certain a lot of great music will be created with it once you've completed it.

[bjporter]

This isn't a VST? OMG this should be a VST

[murnau]

Over $90.000 funded. I can't comprehend why the updates take so long.

PS. $60,000 -- VST plugin version! (imitone and imitone prime)

An imitone VST plugin would operate inside rather than side-by-side with compatible music programs, allowing it to share low-latency inputs on Windows and more tightly integrate into advanced workflows. The VST would be for Windows and Mac and would be included with imitone and imitone prime for all backers.

[interactopia]

What is your erstimated time frame form delivering your stretch goals! Have you even started to do a VST conforming prototype framework for your algo?

Again, the general plan is to wait until the central promises of the campaign have been fulfilled, rather than delaying those for the sake of stretch goals. Most likely, that means I'll be working on the VST and mobile versions after the desktop software is feature-complete.

Porting the algorithm to VST is trivial; the GUI, though, will be significantly more work. Additional research done these last few days suggests it may not be as rough as I'd initially been led to believe, though.

Your installer actually killed my nicely working LoopMidi setup...

I licensed the LoopMIDI driver from Tobias Erichsen for use in imitone. The version Tobias gave me was, at the time, a beta which was incompatible with public versions of LoopMIDI, and users needed to download a beta of LoopMIDI to solve that problem. I haven't tested yet, but at a glance it looks like the updated LoopMIDI is out of beta, which should eliminate this problem.

Latency is measurably lower when using the integrated VirtualMIDI driver, as compared to a loopback application like LoopMIDI. It's also quite a lot more convenient, except in the case where imitone is closed and the DAW does not support hot-swapping.

But I'm sure everybody else (= most pro users) would much prefer a fully integrated VST.

As far as I understand, the majority of my users are not professionals. My primary agenda for imitone is expanding the accessibility of music software. (Hence the low price point.)

Any other company developing this technology would likely have shipped a 1.0 much sooner, at a much higher cost, with an unreliable algorithm, VST and mobile versions. Make of that what you will.

[Uncle E]

As far as I understand, the majority of my users are not professionals. My primary agenda for imitone is expanding the accessibility of music software. (Hence the low price point.)

I believe KVR has millions of members and 99% of us would technically not be considered professionals. I believe most KVR members would only be interested in Imitone if it can be used as a plugin.

Any other company developing this technology would likely have shipped a 1.0 much sooner, at a much higher cost, with an unreliable algorithm, VST and mobile versions. Make of that what you will.

My experience is mobile versions usually arrive separately (usually after). Anyway, you're in a great position in that you already have direct access to your funders, why not just poll them to find out what they really want? People would probably feel good about having a say in the direction of development.