Is SonicBirth dead? No, it's being rewritten!

[metal_head_82]

Hey folks,

I wonder what's going on with SonicBirth...
Latest news on SourceForge is nearly 2 years old. Is the Prject dead? What about planned new features?
Perhaps a new Framework which enables users to open exported PlugIns without having SB installed?

Anything new?

I really like SB so I would love see it under further development...

Greetz

[Kewl]

Perhaps a new Framework which enables users to open exported PlugIns without having SB installed?

Do you mean "open" or "use"? Like in "open to edit" or "use in a audio host application".

- Daniel

[metal_head_82]

Perhaps a new Framework which enables users to open exported PlugIns without having SB installed?

Do you mean "open" or "use"? Like in "open to edit" or "use in a audio host application".

- Daniel

In this specific case I meant "use in an audio host application"...

But I think that's just a little dream I have to put aside. Because of the structure of SB.
It more interesting if there's a general progress in development.
No news in such a long time makes worry...

[eigentone]

Hey folks,

I wonder what's going on with SonicBirth...
Latest news on SourceForge is nearly 2 years old. Is the Prject dead? What about planned new features?
Perhaps a new Framework which enables users to open exported PlugIns without having SB installed?

Anything new?

I really like SB so I would love see it under further development...

Greetz

Hi metal_head_82,

SonicBirth's development has not ceased. Thousands of files have been modified or added within the SonicBirth project over the past 2 years. SonicBirth 1.5 is under development, major commits have been made to support this. Having said that, SonicBirth 1.5 is still far from ready for the public. This would be a good time to remind people that we are looking for more developers, particularly developers who'd like to focus on the UI.

What's changed in 1.5 (so far)?

It provides several significant changes to the audio rendering engine (independent element developers, heads up). Basically, much of the audio rendering has moved or is in the process of moving from (programming languages) Objective-C to C++.
The serialization implementation has been overhauled.
64 bit. This runtime may not be available in the initial public release of 1.5, but it has received a lot of time to date.

In the greater scheme (project roadmap), this would be the stable basis of 2.0. As development is currently shaping up, v1.5 = core, v2.0 = features and interface. I'd say it is too early to ask you (all) what features or system requirements you'd like to see in 2.0, because development for them is so far out. There's nothing preventing you from discussing them here at KVR, but there will not be many new features in the near future unless more developers sign on (I would not classify the 1.5 changes as 'features', per se, more like improvements and enhancements).

As far as dropping the framework requirement (which I've seen requested several times over the years).

I would guess the primary reason for this request is for commercial distribution of exported plugins. If so, then the most logical route in my eyes (hypothetically speaking regarding feature set) is to provide a sub-plugin interface, whereby exported SonicBirth plugin instances load code and resources from some predetermined location (i.e. the plugin bundle, or, like SonicBirth.framework, a shared library at a common library location). There is a runtime restriction in OS X which makes the loading of user interface code very restrictive for plugins. I can explain this, but it may not make sense to people without backgrounds in software development. The changes in 1.5 are a big step towards this goal (though framework independence was not the primary motivation for these changes), but the cost of attaining 'framework independence' would be relatively high. 'framework independence' in this case would mean a restricted feature set for the average user; the musician/engineer who is just building for fun, curiousity, or for a new effect, or somebody who is using somebody that person's SB creation. I am more inclined to develop features for the majority, but I see the majority as freeware and builders for private use. If the free/sharing user base is not the majority, let me know. The restrictions which I referred to earlier could mostly be avoided, if we had a good engineeer who had a lot time, but neither Antoine nor I have the time to realize 'framework independence with minimal feature loss'. Aaaanyways, if commercial development is what you are after, then the best solution (in an optimistic sense) would still require that the plugin developer (i.e. you) would write real code and create real resources (NIBs, images) for the UI. I can imagine how a framework free UI builder *could* be created for SonicBirth, it would be very complex and time consuming to implement, but I am pretty sure it would work. The plugin binary for this would be large. So, the short of framework independence is that it would be a significant step back from 1.3.x wrt UI for SB developers and end users, and that you would have to write the UI code for your plugins, because I don't expect a developer to approach one of us and offer to invest months or years of free development time to create a UI builder for SonicBirth that is good enough to satisfy commercial developers. The framework allows SonicBirth's developers to write normal ui code, and for you to use them in a reliable and predictable manner across framework releases (in most cases). Having said all that, is framework independence really worth it? I just have this feeling that framework independence is generally a request from commercial developers, who would want UIs good enough to not hurt sales, in which case, a plugin interface which loads your UI code would be the best compromise in my opinion... but how many people are out there, who would sell plugins, who would write their UI using NSViews and use SB for processing? I would guess the answer is 'very few', because most people would (at that point) use SB to prototype, and just implement the audio processing in an AudioUnit. There are many more who would use it to sell plugins, if they could design the UI 'in house' and not have to learn a C based language (or hire somebody to write that part of it), but writing that framework independent ui builder would require a lot of development time (est. 1 - 2 man years) to get to a respectable/usable state, and more like 5-10 man years to get it great (though that would be a large binary to redristibute/load with every plugin). Sorry for thinking out loud on this; let me know if I've got something all wrong.

For features that *I* would like to see, I think extensibility (i.e. write your own element libraries in C++) and core engine improvements (i.e. per-unit graphs which would allow IIRs to be constructed easily) are the best use of development time.

Extensibility is good so other developers can get involved more easily. SonicBirth includes many elements, and I think we all could come up with an idea for a new element every day that we make music However, I think it has reached the stage that we should try to place most of the element development in your hands. Of course, the core element set would be expanded in the future and new elements and technologies would become available, but I'd prefer to see general elements made by the SonicBirth community, rather than:
1) requesting us to make each element
2) develop it
3) put the element through the test and release cycle
4) add it to the general SonicBirth distribution
5) support and maintain it for years

Extensibility would be most likely be implemented as an executble plugin interface. To date, the only way to add elements is to check out SonicBirth, build and modify SonicBirth itself. With the plugin interface supported, somebody could create their own filter or slider, they could build a plugin using SB's UI, and redistribute their SB AU with these additional binaries.

Unit accurate graphs: I find it difficult to construct processors in SonicBirth at a low level. At a low level, circuits render several samples at each render invocation. This limitation prohibits you from creating most simple filters using elements. The problem with this: it would require significantly more CPU because we just don't have the developer time to do it 'right'. Doing it 'right' would require a live re-assembler, or something to that effect. This re-assembler would take bits of executable code, piece them together according to the circuit's structure, then the re-assembler's output would be executed during render. A traditional approach (i.e. polymorphic object methods) would make SonicBirth several times slower. You would be able to make circuits which are much more complex. It's a bit of a tradeoff, ultimately, I think unit accuracy is a necessity for low level circuit developers, and we should implement it. Again, this would be several times slower than 1.3.x, since I do not expect somebody to write the re-assembler bit anytime soon.

If you look at those 2 features optimistically, they could balance each other out performance-wise (or even improve), though that would require a bit of external element development. I really don't expect somebody to (ever) write the re-assembler.

As far as major features, that's what I'd like to see the most. These two fetures are the best two that I know of for maximizing circuit and binary modularity (i.e. SonicBirth's capabilities). The downside is that without low level circuit or element developers, these changes would just be performance regressions. So we'd need some people actively using these new technologies in order to make them worthwhile.

Feel free to continue the conversation. I was simply planning on bringing up the topic here at KVR (or wherever the main forum is), and discussing what people want to see regarding technological and feature advances. I'd also ask about system requirements and other potential changes. SB is still rooted on Panther's technologies... we should probably move forward in this regard to support new technologies, like 64 bit, Garbage Collection compatability, ObjC 2 ABI, how long to continue PPC support (now that Snow Leopard is available), and so on. Some of these changes are not trivial, they could reduce and/or increase compatability. What is more important, compatability with a host that is 5 years old, or compatability with the host that will come out next week? The answer is obvious to some people, but I do not expect their answers to be unanimous so... I plan on asking here to get a good idea about what you want to use SonicBirth for in the future once 1.5 is stable. If some things need to break in order to implement these changes, I'd rather they were broken only once.

Cheers,

Justin

[metal_head_82]

I get your point.
It's just because so much time has passed without any update.

I wish I could help you guys but I don't have any coding experience that could be any help for you.
If you need some graphics or animations or sound samples... anything like that, I could help you.

Keep on going. SonicBirth is such a great software.

[eigentone]

I get your point.
It's just because so much time has passed without any update.

I wish I could help you guys but I don't have any coding experience that could be any help for you.
If you need some graphics or animations or sound samples... anything like that, I could help you.

Keep on going. SonicBirth is such a great software.

Yes, it has been a long time between updates.

If anybody is interested in helping, there are always things that can be done which require no coding experience:
Testing
Quality Assurance
Graphics/Images, and other UI resources
Documentation and usage tutorials
Adding Localizations (i.e. translating the app and documentation to another language)
Enhancements to the circuit libraries: Maintenance, creation, compilation of 'factory content'.

I could go on, but you see there is plenty to do at this time. If you are interested, just let me know what you'd like to work on by private message. Since testing and QA depend on developers' output, there may not always be something to do in those regards, but you could be on standby for QA updates while working on other aspects when QA demand is low. If responses are high, then we should solidify feature sets and system requirements for the next major release.

Thanks,

Justin

[Jee-Bee]

Last update was about 2 years ago how far is version 1.5 now??

Jee-Bee

[eigentone]

Last update was about 2 years ago how far is version 1.5 now??

Jee-Bee

Hi Jee-Bee,

The last source commit I made was actually on aug.2.2011 (note: that was into an experimental branch people should not use).

Unfortunately, I have only had time recently for 1-2 man weeks per year for SonicBirth. If development continues at that rate, it would unfortunately be quite some time before this major update I've been working on is ready for human consumption.

J

[makira]

Hi,

I've started a complete rewrite of SonicBirth. It's coming along nicely.

The biggest changes are:
- sample based processing instead of buffer base -> a feedback loop is now only one sample of delay
- no more framework needed

Cheers,
- makira

[Kewl]

Hi Antoine,

Wow! Really? This is very good news!

The most recent version (1.3.1b2) is still working like a champ (which I think is a testament to your coding skills), but any update that keeps SonicBirth alive on the long haul is a great news.

[RogerJoensson]

"sample based processing instead of buffer base" -Absolutely fantastic!

"No more framework" -Doesn't hurt either!

-Am I still asleep (dreaming), I wonder.
When do you expect it to be ready for a test run (early, unstable, whatever)?

[makira]

I expect to have a very basic set of feature for a 0.1 alpha in about a month:

- just basic elements (algebric, functions)
- export as audiounit effect
- no midi, fft, custom gui, debug elements, points, etc

I've only started last Friday, but here's a small taste:

2 poles 2 zeros filter:


sine generator (input is frequency, in the parent circuit):


As you see, most of the elements that are currently black boxes (ie filters, generators) in v1 will be rewritable directly in sb2.

Cheers,
makira

[Coil]

64 bit

[makira]

64 bit :?:

both 32 & 64 bits

[tremblap]

this is the best return of holidays news so far!

thanks for the hard work

pa