.uhm wavetable scripting inconsistencies

[u-u-u]

I spend some time with uhm scripting wavetables and I just hit a conceptual wall (or maybe I just don't get it) and discovered some stuff that seems a bit odd to me

1. The sample accessor functions (main_fi, aux1_fp, ...) only work in time domain. But I need them in the Spectrum (and probably Phase) as well!
   • E.g. if I want to shift the harmonics of an existing frame by 2 I want to write the formula

     Code: Select all

     Spectrum "main_fi(frame, index-2)"

     But this isn't possible because main_fi will always access the samples in the time domain. I don't think there are so many useful cases where I would want to access sample values when calling Spectrum or Phase. Rather I'd expect main_fi to access the sample buffer I'm currently working in.
2. The uhm Wavetable scripting reference is still incomplete / contains some errors
   • The documentation for the 3 last morph types of the Interpolate command are still missing
   • For the "Move" command the example shows that there is a "Source" parameter but it isn't listed above
   • The "Start" parameters default to 0. The "End" parameters default to NumFrames. This is confusing. Are there NumFrames+1 frames then?
     (In the most examples start and end both are 0 for single-frame operations so I guess the "End" default actually is NumFrames-1 but the scripting reference tells something different)
3. This is more a request than a problem: It would be very handy if I could write negative frame indices for "Start" and "End" to describe indices in relation to the last frame index. for the "Start" and "End" parameters . E.g. if I could write:

   Code: Select all

   Wave Start=0 End=-1 "0" //set all frames to zero. -1 stands for NumFrames-1 (the last frame index)
   Wave Start=-3 End=-1 "0" //sets only the last frame to zero. -3 stands for NumFrames-3
   

Are there any answers to those problems already or do I have to send them in as feature requests?

[Urs]

Well spotted!

I can't remember exactly why the sample accessor functions only work in the time domain. I'm not even sure there's a reason for this. Maybe it's bug even, I'll make a ticket and investigate when we get back to this.

The documentation of the Interpolation modes for the wave morphing algorithms is bit on the controversial side. They are more abstract than anything else and might fill an extra documentation easily the same size as this guide itself. The choices were "drop them for ease of use" or "keep for experimentation". I went for latter.

The Source parameter of the move command is indeed missing in the documentation. My omission. It's quite easily guessed though as it's used in a consistent way. Like Source in Export you can specify main, aux1 or aux2 as the origin of the frames you wish to move (in case Source != Target, move always duplicates frames, i.e. it copies and pastes)

Yes, End should default to NumFrames-1.

I'm happy to discuss negative frame numbers. I'm afraid it might be a concept that adds more confusion though.

In the greater scheme of things, we will certainly revisit .uhm scripting as we put it into another synth. There might be a chance to address some of the topics.

[u-u-u]

Thank you for the quick answer!

I can't remember exactly why the sample accessor functions only work in the time domain. I'm not even sure there's a reason for this. Maybe it's bug even, I'll make a ticket and investigate when we get back to this.

Sounds great!

The documentation of the Interpolation modes for the wave morphing algorithms is bit on the controversial side. They are more abstract than anything else and might fill an extra documentation easily the same size as this guide itself.

Maybe a visualization could help? (Although I can imagine that it's a bit hard to explain)
The thing that irritated me here was that morph1 seems to work as I have "zerophase" selected as wavetable Interpolator inside Hive. (that might be a wrong assumption)

I'm happy to discuss negative frame numbers. I'm afraid it might be a concept that adds more confusion though.

Yeah, I agree concerning that confusion aspect. Also I don't think it's absolutely necessary. The thing that bugs me as a programmer is that I I can't just reuse the NumFrames value but have to type/copy it. That's fine for the formula statements as I have the normalized "table" variable here. But for the "Start"/"End" it's inevitable ATM. (Negative frame numbers would solve that while avoiding the introduction of formula parsing for the "Start"/"End" parameters)
Also that a script can't dynamically adapt to the number of frames given by an imported wavetable/script.

In the greater scheme of things, we will certainly revisit .uhm scripting as we put it into another synth. There might be a chance to address some of the topics.

Definetly looking forward to that synth! If you use my proposals, please send me a free license Just kidding. As a programmer I know it's a lot of work to implement at least some of the many ideas flying around.

As we are at ideas: Did you try what wavetables sound like if you play around with partial ratios? (Loading wavetables into an additive synth). I thought about that recently but didn't play around with it yet.