## Q: I want to build a device using the Dynatube cabs...

Scope and XITE Development

Original topic on PlanetZ: https://forums.scopeusers.com/viewtopic.php?t=24856

#### Q: I want to build a device using the Dynatube cabs...

Posted: Sun Mar 30, 2008 7:26 am
by voidar
Thing is, I am a total SDK newbie.
I'll restrict myself to four dedicated devices at first (mesa, marshall, vox, fender), so I need to do some IFs based on the project sample-rate to load the right module (44.1K or 48K) and then I guess I would need to use the dynamic voice of parent-thing.
Anyway.. The the big Q:
Is project sample-rate a val easily accessible?
And I guess I have another Q.. If I succeed in building this device, would I in anyway impact on copy rights if I would release it in the Device-section? I don't think so as you would need a card registered with DT for it to work in the first place, right?
I seem to remember a similar discussion on use of the FleXor atoms.

####

Posted: Sun Mar 30, 2008 7:58 am
by Immanuel
I think the people from Sonic Core would be the ones to give you the best answers on the part about rights. Dynatube is not part of SDK, so you are applying something out of context - though it is released by the same company.

####

Posted: Sun Mar 30, 2008 8:06 am
by voidar
But what I am in essence doing is interfacing with a hardware-protected module. Idealy at least.
I could make a small device that only loads the correct device similar to the way Dynatube does it. It would in essence be just as "criminal" as pulling a cab module into your SFP-project.

####

Posted: Sun Mar 30, 2008 9:41 am
by Shroomz~>
Why would you want to access the project sample rate from your device instead of the project sample rate window? If you want to toggle your device between different sample rate modes all that's really needed is a val switching system for the divisor pad of any delay-based range text modules that you're using so that they read out the correct delay time values for the current sample rate. Maybe I'm missing the point of what you want to achieve?

####

Posted: Sun Mar 30, 2008 10:09 am
by voidar
Yes, you are missing the point a bit (but good tips!). I guess I need to be more direct then . My bad really as not everybody knows the following.
Dynatube comes with two versions of each amp and cabinet module, one for 44.1KHz and one for 48KHz. They both internally oversample and Dynatube won't run in 96KHz.
So the problem is: my device needs to know what the project sample rate is set to so it can load the correct module. running the 48KHz module @ 44.1KHz rate, or wise versa, has audiable effects.

####

Posted: Sun Mar 30, 2008 10:20 am
by Shroomz~>
Ah ok, I'm with you now. So you're saying that Dynatube automatically loads the correct one depending on the currently set project sample rate?

####

Posted: Sun Mar 30, 2008 10:44 am
by voidar
Yes, that is what happens. Also, if you have samplerate set to above 48KHz, a box will appear soberly stating that DT won't load under these settings. So there is definitely some logic applied at loading.
If there is no real way to look up sample rate and ULLI, then maybe one would need to construct some sample-counter or so. That is if there is some real-world clock available.

####

Posted: Sun Mar 30, 2008 12:23 pm
by Shroomz~>
There must be a way to access the current global/project settings.

####

Posted: Sun Mar 30, 2008 11:08 pm
by Warp69
Im also looking for something like that. VDAT have the same functionality - can display the chosen samplerate.
I have a DSP module that can determine the samplerate with a loop, buts its a Sonic Timeworks DSP file and I can therefor not distribute that file. But I would much rater have a module that have access to project settings so it can determine the ULLI settings.
Cheers

####

Posted: Tue Apr 01, 2008 2:58 am
by voidar
I've got a couple ideas at the moment. First thing I could try to build a digital counter using logical operands.
Another idea would be to compare two sines. One controlled by a frequency val and one controlled by a time val. If the time variables are anything to count on, the one controlled by the time val should change it's output based on the set samplerate.

#### Sample rate detection

Posted: Wed Apr 02, 2008 3:31 pm
by voidar
Ok, I've succeeded in building a preliminary device which lets me utilize dynatube cabinet models as well as set the mic-position. Also, the correct model (44.1K or 48K) of a cabinet is used based on sample rate.
However, for reasons I don't understand, the device crashes Scope when I delete an instance from a project, but otherwise works efficiently. Any ideas?!
Anyway, I thought I would like to elaborate a bit on my sample rate detection. My current solution only knows how to detect 48K and "every-thing-else", as in not 48K.
It works and does suit my needs as of now for this particular device, but I am pretty sure I know how to create a detector that will be able to do 32K, 44.1K and 96K as well, and which will be far from as ugly as my current solution ..
In SDK, If you drive an OSC with a ranged text controller, let's say one that says "1 Hz", you can be sure the OSC stays at that pitch at any given sample rate.
Enter the async2sync atom.
If you where to drive the OSC with the same ranged text controller via the a2s, the OSC pitch will be scaled depending on set sample rate.
Knowing this, you now have a means to compare a static value and a value that responds to sampling rate - the relation should be able to tell you what it's set to.
It would also help to know that at 48K, both values share a 1:1 relation, as in they are in "sync".
Interestingly, this tells me that the hardware-interfacing is built around 48K operation as its default rate.

####

Posted: Thu Apr 03, 2008 12:23 am
by tgstgs
congratulation;
you find a way and bring light where others walk trough the dark
for me THIS is true development;
-> make things work to satisfy the needs!
and let me add it only takes a few cycles;
go on now dont stop;
there might be similar effects with the ully no?
good vibes to norway

####

Posted: Thu Apr 03, 2008 10:00 am
by voidar
For those that won't bother constructing one themselves, I hereby share my device. Now detects 32K, 44.1K, 48K and 96K.
I ended up using a Ranged Text controller, async2sync and three Ifs, and Or and NOr.
As for ULLI I would have no idea :/. I think you would need some sort of loop-back for that. Not very transparent at all.

Attachments
  SR-Detector (working).zip
    &quot;Sample Rate-detector&quot; working
    (6.18 KiB) Downloaded 119 times
  SR-Detector.zip
    &quot;Sample Rate-detector&quot;
    (7.51 KiB) Downloaded 109 times

####

Posted: Thu Apr 03, 2008 10:46 am
by Warp69
Very impresssive Voidar.

####

Posted: Thu Apr 03, 2008 11:50 am
by voidar
Thanks.
I added an update. For some reason I could not get it to detect 44.1K in regular SFP.

####

Posted: Fri Apr 04, 2008 10:06 am
by Warp69
Some information :
Every time Scope starts it has a module loaded called WordClockPipe - the top module in the Project Explorer. The tap "MFreq" determines the Sample Rate :
Value 0 : 32KHz
Value 1 : 44.1KHz
Value 2 : 48KHz
Value 3 : 96KHz
You just copy that module inside your device.
Im also able to read the ULLI setting, but unfortunately not in realtime - I'll have to reload the module if I change the ULLI setting - it then shows the correct value again. I'll have to look more into this.
Cheers

####

Posted: Fri Apr 04, 2008 10:16 am
by voidar
LOL! That easy was it ..
Thank you for this. That makes my module pretty excessive.
I think Scope needs to restart on every ULLI-change anyway, right?
Greatness!

####

Posted: Fri Apr 04, 2008 10:27 am
by Warp69
As stated before - Im quite impressed with your approach.
Well - here it is: www.relab.dk/SampleRate.mdl - shows both the sample rate and ULLI setting.
Cheers

####

Posted: Sun Apr 06, 2008 12:52 am
by wolf
Very nice trick & observation, Voidar !
I still fail to find a difference in values though, when changing SR

> That makes my module pretty excessive.

Not at all. The small drawback of the wordclock module is it sets the project SR settings to the given setting, so it may change your current project setting (i.e. from slave to master like in my case).
Btw, here you can find a module, which reads out ulli only :
http://wolf-audio.com/dev/ulli-readout.zip
Still not realtime, but in DP/SDK you can right click on it to read out the actual value from cset.ini.

####

Posted: Tue Apr 08, 2008 5:01 am
by voidar

> wolf wrote:Very nice trick & observation, Voidar !
> I still fail to find a difference in values though, when changing SR

> > That makes my module pretty excessive.

> Not at all. The small drawback of the wordclock module is it sets the project SR settings to the given setting, so it may change your current project setting (i.e. from slave to master like in my case).
> Btw, here you can find a module, which reads out ulli only :
> http://wolf-audio.com/dev/ulli-readout.zip
> Still not realtime, but in DP/SDK you can right click on it to read out the actual value from cset.ini.

You mean my SR-detector isn't working for you?
It sometimes gave me a hard time getting it to work as it could be very inconsistent. But when it does, and you save it, it works here, at least the updated one. The old one would work in SDK, but not in SFP (for 44.1K) for some reason.
If you handle the wordclock module correctly I see no real danger really. Though seeing as controllers are biidirectional, I see how one could accidentally set something instead of reading.

####

Posted: Tue Apr 08, 2008 8:59 am
by Shroomz~>
To make the connection read only/unidirectional, just insert a diode.

####

Posted: Tue Apr 08, 2008 11:10 am
by wolf

> voidar wrote: You mean my SR-detector isn't working for you?

nono, it works fine. It's just I don't get it rebuild by hand with your explanation above .. little fool I am, hehe.

> It sometimes gave me a hard time getting it to work as it could be very inconsistent. But when it does, and you save it, it works here, at least the updated one. The old one would work in SDK, but not in SFP (for 44.1K) for some reason.

ok, you got fooled, too

> If you handle the wordclock module correctly I see no real danger really. Though seeing as controllers are biidirectional, I see how one could accidentally set something instead of reading.

The point with the wordclock module is -> it sets SR and master/slave without having any connections done. A Diode doesn't help here, Shroomz.
For a short test: save WC module, change SR setting, load WC module

####

Posted: Wed Apr 09, 2008 6:32 am
by voidar
Yes, I discovered the WC module acting like this, so I went back to my SR.
EDIT: I wonder if having a controller pad hooked up to the main/project WC-module via store/connect will work?
I solved the 44.1K issue with some logical gates, so now 44.1K output only goes 1 when the others are 0.
All in all it is a very frustrating device to build, and I suspect it is because async values only update "when they have to".
Thus try hooking the sync output to an osc. Things should start to work. If not, replace the ifs that don't work.
When everything works fine, just delete the osc, move out of the sub circuit, check if it works and save it.