| Author |
Message |
DrJustice

Joined: Sep 13, 2004 Posts: 2112 Location: Morokulien
Audio files: 4
|
Posted: Sat Jul 26, 2008 11:01 am Post subject:
|
 |
|
Aha - Right, SynthEdit may impose restrictions on feedback. BTW, alledgedly SynthMaker allows it. But I'm not really familiar with either. Sorry for the slight OT.
DJ
-- |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Sat Jul 26, 2008 11:56 am Post subject:
|
 |
|
| DrJustice wrote: |
Surely, inside your own VST wrapped algorithms you can use feedback all you like. It would be across VST's the block processing presents a problem. Or am I missing something?
|
Yes, in a perfect world. In practice most computer-based modulars use block-processing in a way that doesn't jive so well with feedback.
Of course without feedback at all there would be no IIR filters in such systems which would be a bit silly but there is a difference between inter and intra module feedback.
For example; I think that in Reactor you can do feedback properly but they had to buy Sync Modular and use their Z-1 module trick in such loops. Tassman, which has lots and lots of modules that are themselves based on feedback, still has trouble with feedback around the modules itself, I think.
Just because you can *patch* feedback doesn't mean it will work properly. For this application where delay times are so short that a sample's duration is relatively long compared to it I think adding the block-size to the loop is a big deal; no unresolvable issue, probably, but something that needs some care. _________________ Kassen |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Sat Jul 26, 2008 11:59 am Post subject:
|
 |
|
| DrJustice wrote: | Sorry for the slight OT.
|
It's not. I feel this is a highly topical issue, especially now that we are looking into context-sensitive block processing for ChucK to get the CPU boost where we can yet also get a proper z-1 where we need it, within the same program.
Well, ok, Ge and company are looking into that, the rest cheers them on ;¬) _________________ Kassen |
|
|
Back to top
|
|
 |
DrJustice

Joined: Sep 13, 2004 Posts: 2112 Location: Morokulien
Audio files: 4
|
Posted: Sat Jul 26, 2008 12:05 pm Post subject:
|
 |
|
Yup, I got that: a block processing based modular has been used inside the VST in this case. That is a limitation of said modular, not of what can happen inside a VST. So I assume we can agree that VSTs does not preclude feedback for the algorithm embedded inside it.
Edit: to add: I'm surprised that seemingly all modular systems have issues with feedback. In my ideal world, per sample processing would be the one thing to embrace with the increase in CPU power and memory bandwidth.
DJ
-- |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Sat Jul 26, 2008 12:12 pm Post subject:
|
 |
|
| mosc wrote: | | Every type of convolution based ambient processor I have heard, except for some special exceptions, sound like reverb to me. I'm not against convolution processors as a musical effect or as a piece of kit in the electro-musicians tool set. The reference to BS was that convolution itself is separate from ambiophonic reproduction. It's something Ralph adds to get an effect he likes, but convolution is a completely independent process and it can added to straight stereo and straight 5.1. It really shouldn't be included in a discussion of ambiophonics. |
Well, you *could* implement Ambiophonics using convolution. You'd lose the infinite tail but as I think that as feedback is generally fairly low that's no big deal, you would be sure rounding errors don't carry as well as losing the feedback itself. That could be a advantage in some cases... but for general purpose CPU's I don't think it makes much sense.
| Quote: | | One more thing, that might interest Kassen especially. I developed the processor on the G2. It's very easy to experiment. There are two problems with the G2. One is that I don't like using such a valuable piece of hardware for processing my music. The other is that piping music out of my MOTU, through the G2 and back, causes a slight, but definite, audio distortion. I assume this is caused by the DA - AD - DA - AD chain one experiences when using any outboard analog processor. (Well, technically the middle conversions aren't there with analog, but you get the analog distortion of anyhow). Kassen has stated that he finds the G2 converters aren't. well, let's say, as good as they could be. In this case, it's certainly a noticeable effect. |
You have a extra conversion; the G2's delays drop, then add, some bits. That means vertical flanks which is exactly what the G2's dac's find hardest to deal with.
Aside from that; you paid for a G2 anyway and it's fan-less, that might count in favour of using it... but for this application the quality of the delay is rather important. I think a interpolating delay would be better here then the G2's one which seems aimed more at musical usage then as a DSP building block to me.
I have to admit that right now I'm finding the questions around implementing it more interesting the the Ambiophonics itself :¬) _________________ Kassen |
|
|
Back to top
|
|
 |
Kassen
Janitor


Joined: Jul 06, 2004 Posts: 7678 Location: The Hague, NL
G2 patch files: 3
|
Posted: Sat Jul 26, 2008 12:21 pm Post subject:
|
 |
|
| DrJustice wrote: | | Yup, I got that: a block processing based modular has been used inside the VST in this case. That is a limitation of said modular, not of what can happen inside a VST. So I assume we can agree that VSTs does not preclude feedback for the algorithm embedded inside it. |
Yes, quite so, I'm in full agreement.
| Quote: | Edit: to add: I'm surprised that seemingly all modular systems have issues with feedback. In my ideal world, per sample processing would be the one thing to embrace with the increase in CPU power and memory bandwidth.
|
Not all; ChucK doesn't have the slightest problem with it, everything that does not depend on the OS (like input devices) is *at least* sample accurate and many things are orders of magnitude more accurate, in fact I think you can define things to more accuracy then the clock of the underlying CPU. Of course that only affects execution order and the eventual audible effects will be quantised to the next sample but that means that when you have a loop that runs at some rate that's not a integer multiple of a sample's duration rounding errors won't carry (well, not beyond the rounding errors of double floats).
It's really quite nice :¬).
(though of course you pay for it in CPU cost) _________________ Kassen |
|
|
Back to top
|
|
 |
Tekas
Joined: Dec 13, 2008 Posts: 2 Location: Portugal
|
Posted: Sat Dec 13, 2008 9:44 am Post subject:
Re: Improved Chuck Ambiophonic Processor |
 |
|
| mosc wrote: | | Here's an improved Ambiophonic processor. After much experimentation, this is the best algorithm I have tried. (...) |
I'm sorry for sneaking in, but I was searching for some ambiophonic algorithms and yours is definetively worth trying. The apparent easy of implementation is an extra.
I'm trying to translate your code to SynthMaker, but I can't seem to understand it very well, so I can't get it to work, even at a small scale.
If I understand correctly, the "-1" notations on the sketch are phase-invertions, right? If affirmative, so far, so good. The problem I seem to be facing is with the "+" notations. Are they a single gain variable or different for each section? What values seem to work best?
I'm using a global variable, tested from 0.1 to 2 and I can't seem to make it work, so there must be something I'm doing wrong. |
|
|
Back to top
|
|
 |
blue hell
Site Admin

Joined: Apr 03, 2004 Posts: 24493 Location: The Netherlands, Enschede
Audio files: 298
G2 patch files: 320
|
Posted: Sat Dec 13, 2008 10:15 am Post subject:
|
 |
|
Tekas, maybe also have a look at : http://electro-music.com/forum/forum-164.html , Howard (mosc) made something for SynthMaker I think. _________________ Jan
also .. could someone please turn down the thermostat a bit.
 |
|
|
Back to top
|
|
 |
Tekas
Joined: Dec 13, 2008 Posts: 2 Location: Portugal
|
Posted: Sat Dec 13, 2008 10:21 am Post subject:
|
 |
|
Thank you so much for your patience and quickreply Blue Hell!
I am today so emerged in this that my searches don't turn up very well.
Thank you once again.  |
|
|
Back to top
|
|
 |
blue hell
Site Admin

Joined: Apr 03, 2004 Posts: 24493 Location: The Netherlands, Enschede
Audio files: 298
G2 patch files: 320
|
Posted: Sat Dec 13, 2008 11:02 am Post subject:
|
 |
|
| Tekas wrote: | I am today so emerged in this that my searches don't turn up very well.  |
Google knows everything ... including one's mood  _________________ Jan
also .. could someone please turn down the thermostat a bit.
 |
|
|
Back to top
|
|
 |
mosc
Site Admin

Joined: Jan 31, 2003 Posts: 18256 Location: Durham, NC
Audio files: 227
G2 patch files: 60
|
|
|
Back to top
|
|
 |
mosc
Site Admin

Joined: Jan 31, 2003 Posts: 18256 Location: Durham, NC
Audio files: 227
G2 patch files: 60
|
Posted: Mon Dec 07, 2009 11:55 am Post subject:
|
 |
|
UPDATE: Since releasing the free Mosc's Ambio DSP, I've been working with Robin Miller on improving the algorithm. While my posted algorithm works very well, as does Robin's posted RACE algorithm, we have come up with some improvements to both and incorporated them in a new processor called AmbiophonicDSP. It is available at the electro-music.com online store:
http://electro-music.com/catalog/product_info.php/products_id/114
The improvements based on this collaboration are proprietary. The acoustic result is significantly better. If you like ambiophonic reproduction, I strongly suggest you buy the newest version. You will not only get the best possible stereo reproduction but you'll also support electro-music.com. _________________ --Howard
my music and other stuff |
|
|
Back to top
|
|
 |
|