I saw that this is already mentioned in the "what's coming" page, which is great. But I just wanted to say that multi-core support would be particularly useful for me. I recently got a quad-core computer and while it still is faster than my old computer, it could be much much faster and I'm already maxing out the CPU because of a couple CPU heavy Reaktor patches. Running the same plugins in something like Cockos Reaper puts much less of a strain on my CPU. But of course I just use Audiomulch anyway because I enjoy using it so much better :). Thanks!!
I just wanted to add one more thing, I ran a test so I could get a better picture of the situation. I was running a patch in mulch that was around 50% that I was unable to add much else in the way of plugins or else I started getting buffer underruns. I tried the same thing in a program with multi-core support (reaper), the exact same plugins (and some more) to see the difference, and my CPU meter was pushing 13%. Unfortunately that's too big of a trade-off--I can run 3 or 4 more times the plugins in multi core software. So until the (eagerly awaited) update, I'll have to use Reaper and give up my nice AudioMulch metasurface and midi assignments and mixing. That's just my two cents! And I am very happy with where Audiomulch has been going, keep up the good work!
Thanks,
John
I'd also very much like to see this, along with 64 bit support.
I am aware that for some uses these would be nice things to have, that's why they are on the roadmap. They will come in time. However, improving the core capabilities of the program, such as the MIDI control system, remains a higher priority.
Thanks, I appreciate the response. I understand there's only so much time to add new features and updates :).
Echo bagger288!
hope to see these as high priority for short-term:
* Multi-core audio processing support
* Improve input/output level meters
* Improve GUI performance
* 64 bit executables on Windows and Mac
thanks for the latest updates.
> hope to see these as high priority for short-term:
Thanks for your feedback. In the "short term" the priority is with resolving 2.2 issues (GUI performance is part of that). 2.3 is really "medium term". Aside from "Improve GUI performance" none of the things in your list are a high priority for 2.3.
I think the what's coming page makes it clear that improvements to MIDI control are the highest priority:
http://www.audiomulch.com/info/whats-coming
Multi-core is dependent on a re-write of the sound file streaming system. This is currently in the early stages of development but it is unclear whether it will be prioritised for 2.3, more likely 3.0.
64-bit support is only really of benefit to people using lots of plugins, as such it isn't a super-high priority. What I am currently thinking is that for 2.3 there will be experimental/beta 64 bit builds -- but I doubt that 64 bit support can be stabilised to production quality in one iteration. Another topic with 64-bit is that there is some confusion about whether this just means 64-bit binaries or also support for hosting/bridging 32 bit plugins in 64 bit executables (there are absolutely no plans for that).
I'd sure like to see multi-core support. As for 64 bit, I'm using 64 bit windows 7 but all the hosts I use are 32 bits. I don't really need to swtich to 64 bits hosts. The way I do things is pretty much the same has a few years ago except with higher quality plugins. Mosts hosts seems to stream wavefiles from the hd anyway so I doubt I'll go over the 3-4 gigs of ram that 32 bits hosts can access.
yes, I think multicore would be more important then 64 bit.
To have Audiomulch running on a single core is like forcing a hungry animal to a strong diet with a pile of food right on the other side of his cage...
>>To have Audiomulch running on a single core is like forcing a hungry animal to a strong diet with a pile of food right on the other side of his cage...
Actually the food is on other islands. The zoo builder needs to build a new cage that has many rooms: one room on each island, each linked by bridges. In addition to building the actual cage for "Project Multi-island Mega-cage" the zoo builder also needs to pipe electricity and hot and cold running water to each island and refine many other aspects of the cage design.
All this so that the hungry animal can roam between islands and eat. Actually it's more like a family of hungry animals that want the opportunity to spend time sunbaking in smaller groups on different islands. Often, the hungry animals are not native to the island but are exotic super-hungry imported animals from weird places where they think CPU time grows on trees.
Notice that walking between islands takes time and sometimes the animals will need to queue at the feeding areas. The animals in the zoo are very civilised and take turns and wait for their friends, so even when spread across multiple islands they may not get fed as quickly as you might think -- making the whole idea of building a mega-cage somewhat less worthwhile.
Compared to the above, upgrading "Cage 2.0" to run natively in 64 bit is pretty easy, although admittedly not as exciting.
That said, the zoo builder has spent the last month digging trenches to convey drinking water and electricity between the islands -- but you will be waiting a while to see the final mega-cage. In the mean time the zoo builder thinks that adding useful features such as improved MIDI control is a good idea, and has prioritised this above finishing major inter-island construction works. Especially because the people waiting for better MIDI control have been asking for it for so long that they have all but given up making noise about it.
Or perhaps they are patient Slow Lorises and know that eventually their hoped-for enhancements will arrive, and that it's not wise to bother the zoo-keeper when he's engaged in the multifarious task of upgrading the premises.