@OhWell
Not easy to solve with mixdown though, precisely because it’s just part of the picture.
No it IS easy. You need to understand how mixdown in 96 khz works. In this situation ALL internal processing, everything, is running at 96khz.. it's not just about some final resampling. No no. In this case really audio goes TO and FROM filter in 96khz quality.
It REALLY works this way, you just need to try it. I'm using this all the time Works like a charm - all aliasing issues after doing 96khz mixdown dissapears ...
Just put together few tracks with instruments playing on high resonance .. then do 44khz and 96khz mixdowns (bitrate doesn't matter, but i usually use 24bit because of headroom). Then compare them. You will immediately hear why 96 khz is solution
More i'm thinking about it, except of live performance this (non oversampled filters) isn't issue at all For realtime you have super efficiency, for export super quality. Best of both worlds.
@OhWell
Not easy to solve with mixdown though, precisely because it’s just part of the picture.
No it IS easy. You need to understand how mixdown in 96 khz works. In this situation ALL internal processing, everything, is running at 96khz.. it's not just about some final resampling. No no. In this case really audio goes TO and FROM filter in 96khz quality.
It REALLY works this way, you just need to try it. I'm using this all the time Works like a charm - all aliasing issues after doing 96khz mixdown dissapears ...
Just put together few tracks with instruments playing on high resonance .. then do 44khz and 96khz mixdowns (bitrate doesn't matter, but i usually use 24bit because of headroom). Then compare them. You will immediately hear why 96 khz is solution
More i'm thinking about it, except of live performance this (non oversampled filters) isn't issue at all For realtime you have super efficiency, for export super quality. Best of both worlds.
Too busy to re-read thread to be sure but wasn’t the original point that people were saying that obsidian doesn’t do analog style oscs/filter/saturation/drive etc as accurately as model d? The way each component reacts with each other is modelled very specifically and painstakingly in an app like Model D. 96khz mixdown isn’t going to make obsidian sound/behave like Model D
It’s not a big issue though. Obsidian shines elsewhere and Model D AU exists..
There are always compromises. I think Model D's polyphony on iOS is 4 notes - not sure on how much CPU that uses but I'm guessing there's a good reason for that limit.
Obsidian's aimed at being the built-in workhorse synth and is designed around the 80/20 rule - it gets you by in approx. 80% of cases with approx. 20% of the CPU. There's definitely scope for adding adding further (and more CPU expensive) analog filter types but there's also a good argument for leaving that to AUs where the filter is their USP.
Just a reality check here: I wouldn't try and take on Moog whilst also trying to maintain a DAW sized app single-handed!
Although extra filter types would be viable, adding true audio rate modulation to Obsidian would be stretching it too much. The way I see it, you've got 3 things to balance:
Audio rate modulation (with low aliasing)
Configurable/flexible modulation routing
Voice polyphony
You can get any two of those on iOS, but trying to do all 3 would probably result in Obsidian failing to do the job for which it's intended.
@Blip Interactive said:
There are always compromises. I think Model D's polyphony on iOS is 4 notes - not sure on how much CPU that uses but I'm guessing there's a good reason for that limit.
Obsidian's aimed at being the built-in workhorse synth and is designed around the 80/20 rule - it gets you by in approx. 80% of cases with approx. 20% of the CPU. There's definitely scope for adding adding further (and more CPU expensive) analog filter types but there's also a good argument for leaving that to AUs where the filter is their USP.
Just a reality check here: I wouldn't try and take on Moog whilst also trying to maintain a DAW sized app single-handed!
Although extra filter types would be viable, adding true audio rate modulation to Obsidian would be stretching it too much. The way I see it, you've got 3 things to balance:
Audio rate modulation (with low aliasing)
Configurable/flexible modulation routing
Voice polyphony
You can get any two of those on iOS, but trying to do all 3 would probably result in Obsidian failing to do the job for which it's intended.
Maybe it would be easier to revisit these ideas after track freeze arrives. If multiple instance etc is the no.1 usp for Obsidian then that could still kinda remain if we can freeze tracks. But yeah, bit pointless in terms of effort/reward really as there are plenty of other AU out there. Deeper daw functions should be priority for long in to the forseeable imho.
@Blip Interactive Your description of the 80/20 rule and the 3 things to balance is super helpful in understanding this whole set of issues and the wisdom behind obsidian. Thank you!
This whole discussion (and the other thread that branched out) just made me love obsidian as it currently is that much more!
@Blip Interactive said:
There are always compromises. I think Model D's polyphony on iOS is 4 notes - not sure on how much CPU that uses but I'm guessing there's a good reason for that limit.
Obsidian's aimed at being the built-in workhorse synth and is designed around the 80/20 rule - it gets you by in approx. 80% of cases with approx. 20% of the CPU. There's definitely scope for adding adding further (and more CPU expensive) analog filter types but there's also a good argument for leaving that to AUs where the filter is their USP.
Just a reality check here: I wouldn't try and take on Moog whilst also trying to maintain a DAW sized app single-handed!
Although extra filter types would be viable, adding true audio rate modulation to Obsidian would be stretching it too much. The way I see it, you've got 3 things to balance:
Audio rate modulation (with low aliasing)
Configurable/flexible modulation routing
Voice polyphony
You can get any two of those on iOS, but trying to do all 3 would probably result in Obsidian failing to do the job for which it's intended.
That explanation makes sense to me. I admit that when I first bought NS2 I was a little disappointed by the sound, partly because it was getting so much praise, so my expectations were for something really spectacular. However now that I've got to know the synth a little better I can appreciate its actual strengths: firstly it's by far the most versatile synth on the platform (no contest there), and also it has a lot of modulation options. Secondly it's very CPU efficient, and for an all-in-one app that's really important (along with its versatility). As an aside I'm really liking the sampling synthesis.
So you clearly made the right choices when designing the app.
@OhWell said: @Blip Interactive Your description of the 80/20 rule and the 3 things to balance is super helpful in understanding this whole set of issues and the wisdom behind obsidian. Thank you!
This whole discussion (and the other thread that branched out) just made me love obsidian as it currently is that much more!
I agree. I have also discussed the relation of Obsidian to other iOS synths elsewhere - I like discussion and always like to look at all sides of a coin.
I would like to say to @Blip Interactive that in no way was I looking at changing what Obsidian clearly is and is clearly good at. Obsidian is a well designed built in workhorse synth that allows us to use many tracks within the early stages of a musical idea. While some may ask if additions could be made in the future, I’m sure that many of us are quite happy with what Obsidian is at this time. Personally, I would much prefer the limitations of resources (especially time) to always be spent on additions towards stability, ease of use and any additions to be carefully weighed against what is already available.
I’m sure sometimes discussion of ‘what we don’t have’, can sometimes be disheartening from a developers perspective. However, the majority of us live in the real world and are quite aware of what is likely and possible considering limited resources and time - feel supported and try not to take discussion to heart in any negative way
Comments
No it IS easy. You need to understand how mixdown in 96 khz works. In this situation ALL internal processing, everything, is running at 96khz.. it's not just about some final resampling. No no. In this case really audio goes TO and FROM filter in 96khz quality.
It REALLY works this way, you just need to try it. I'm using this all the time
Works like a charm - all aliasing issues after doing 96khz mixdown dissapears ...
Just put together few tracks with instruments playing on high resonance .. then do 44khz and 96khz mixdowns (bitrate doesn't matter, but i usually use 24bit because of headroom). Then compare them. You will immediately hear why 96 khz is solution
More i'm thinking about it, except of live performance this (non oversampled filters) isn't issue at all
For realtime you have super efficiency, for export super quality. Best of both worlds.
Too busy to re-read thread to be sure but wasn’t the original point that people were saying that obsidian doesn’t do analog style oscs/filter/saturation/drive etc as accurately as model d? The way each component reacts with each other is modelled very specifically and painstakingly in an app like Model D. 96khz mixdown isn’t going to make obsidian sound/behave like Model D
It’s not a big issue though. Obsidian shines elsewhere and Model D AU exists..
improper reading of what @OhWell wrote from my side, sorry :-)
i'm talking still and all the time just about solving aliasing issue ... will later make some audio example to make last point in this topic..
———————-
i splited discussion about moog emulation(s) - its interesting topic which deserves own thread
https://www.blipinteractive.co.uk/community/index.php?p=/discussion/262/moog-model-d-drc-and-other-moog-like-emulationz#latest
i splited discussion about moog emulation(s) - its interesting topic which deserves own thread
https://www.blipinteractive.co.uk/community/index.php?p=/discussion/262/moog-model-d-drc-and-other-moog-like-emulationz#latest
yum. Filters in series in obsidian = ws into lpf for days. Noice!
Obsidian is so fun!
There are always compromises. I think Model D's polyphony on iOS is 4 notes - not sure on how much CPU that uses but I'm guessing there's a good reason for that limit.
Obsidian's aimed at being the built-in workhorse synth and is designed around the 80/20 rule - it gets you by in approx. 80% of cases with approx. 20% of the CPU. There's definitely scope for adding adding further (and more CPU expensive) analog filter types but there's also a good argument for leaving that to AUs where the filter is their USP.
Just a reality check here: I wouldn't try and take on Moog whilst also trying to maintain a DAW sized app single-handed!
Although extra filter types would be viable, adding true audio rate modulation to Obsidian would be stretching it too much. The way I see it, you've got 3 things to balance:
You can get any two of those on iOS, but trying to do all 3 would probably result in Obsidian failing to do the job for which it's intended.
Maybe it would be easier to revisit these ideas after track freeze arrives. If multiple instance etc is the no.1 usp for Obsidian then that could still kinda remain if we can freeze tracks. But yeah, bit pointless in terms of effort/reward really as there are plenty of other AU out there. Deeper daw functions should be priority for long in to the forseeable imho.
@Blip Interactive Your description of the 80/20 rule and the 3 things to balance is super helpful in understanding this whole set of issues and the wisdom behind obsidian. Thank you!
This whole discussion (and the other thread that branched out) just made me love obsidian as it currently is that much more!
That explanation makes sense to me. I admit that when I first bought NS2 I was a little disappointed by the sound, partly because it was getting so much praise, so my expectations were for something really spectacular. However now that I've got to know the synth a little better I can appreciate its actual strengths: firstly it's by far the most versatile synth on the platform (no contest there), and also it has a lot of modulation options. Secondly it's very CPU efficient, and for an all-in-one app that's really important (along with its versatility). As an aside I'm really liking the sampling synthesis.
So you clearly made the right choices when designing the app.
I agree. I have also discussed the relation of Obsidian to other iOS synths elsewhere - I like discussion and always like to look at all sides of a coin.
I would like to say to @Blip Interactive that in no way was I looking at changing what Obsidian clearly is and is clearly good at. Obsidian is a well designed built in workhorse synth that allows us to use many tracks within the early stages of a musical idea. While some may ask if additions could be made in the future, I’m sure that many of us are quite happy with what Obsidian is at this time. Personally, I would much prefer the limitations of resources (especially time) to always be spent on additions towards stability, ease of use and any additions to be carefully weighed against what is already available.
I’m sure sometimes discussion of ‘what we don’t have’, can sometimes be disheartening from a developers perspective. However, the majority of us live in the real world and are quite aware of what is likely and possible considering limited resources and time - feel supported and try not to take discussion to heart in any negative way
Funny thread.