PlanetZ forums - scopeusers.com

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.

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.

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.

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?

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.

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?

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.

There must be a way to access the current global/project settings.

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

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.

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.

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

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.

Very impresssive Voidar.

Thanks.

I added an update. For some reason I could not get it to detect 44.1K in regular SFP.

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

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!

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

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.

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.