Cherry Audio Forums

Hi

Is there a limit to the number of inner classes you can have? I normally handle Undo by creating an inner undo class for all functions inheriting from this:
public abstract class Undo {
public abstract void Undo();
}

The byte oscillator is by now a fairly large module, when adding some more functionalities I started to get weird problems, the debugger just crashed a couple of seconds after launch. I manager to get rid of it by removing inner classes and could recreate it by adding dummy inner classes (without any function).

The logs didnt give any indication to why it crashed.

Regards
Tobias

Another slightly related problem I have with Designer is with including more than one class in a source file.

This doesn't cause a crash but trips up the source Module menu so much that one can no longer use it to navigate around the code.

I've pretty much given up on the VMD debugger. It's like you need a debugger to debug the debugger while debugging.

My other big problem is that run with external profiler has stopped working. I submitted a post on the forum 6 month ago but no response from cherry audio yet:
viewtopic.php?f=9&t=1077&p=4229&hilit=profiler#p4229

I still think its great that the debugger and the integrated designer is there. Its a good and fast way for new developers to jump into module development. Would be good with a standard defined way to use a purpose built IDE, cant expect the module designer to compete with that, not really their core business.

I agree that CA have done a great job with Designer. It's a fabulous gateway to creating new VM modules.

Forgive me for going slightly off-topic...

The problem is that CA have a tiny number of people working on development. They are clearly extemely talented people but there is a limit to what can be achieved by a small team. My sense is that these people are working flat out and have reached the point of overload. This is a common problem in small companies and can be demoralising as it takes away the fun and creativity.

And it doesn't help when we constantly gripe about problems!

My hope is that there's enough income growth to hire one or two more developers. One way to manage this would be to offload all the Designer side of things to a new staffer. Then the existing team could concentrate on core VM issues and spin-off instruments while the new person would have enough time to enhance Designer, build a bridge to third party tools and handle ancillary tasks like documentation and interacting with external developers. Also the resulting toolset improvement would further boost the productivity of the core team.

Another path would be to go open-source but I hope that doesn't happen as I am really impressed by the work of the CA team and don't want to see that diluted.

Besides the fact that it should not bother the IDE/compiler/debugger/profiler/virtual machine if you define more than one class per source file, is there a reason why you don't (want to) use one source file per class?

Hi, yeah it's just handy to be able to quickly add one or two small helper classes without having to split them off into separate files.

I guess it's laziness on my part.

Laziness is the reason for me as well...