WHY NOT show us the TRUE PARAMETER VALUE? IN THIS CASE, THE

WHY NOT show us the TRUE PARAMETER VALUE? IN THIS CASE, THE hz?


BECAUSE AN ADVANCED SAMPLER, FIRST sampling,
AND AFTER sequencing.


AN ADVANCED SAMPLER,
SHOULD MAKE MANY THING before.
(for example...)




I would prefer to have it in this REAL TIME & VIEW CONTROL OF THE REAL VALUE

OPTION A )



ONLY A SMALL PERCENTAGE OF KNOWLEDGE THAT I HAVE PROVIDED HERE. IT COST A FORTUNE I KNOW IT.


OPTION B)



OPTION C)

Why not? Here's a few thoughts:

How would the UI deal with the exponential scale of frequency? It wouldn't make sense just to have a linear mapping, where one click of the data wheel does a one hertz increment.

Also, it's completely possible that the filter algorithm doesn't actually ever deal with a literal frequency value. In fact, probably likely. It's a sort of arbitrary scaling that doesn't necessarily make the most sense in the coding for a digital filter. So that 0-100 number, that might be more related to the "actual value"—the process happening—than a frequency.

Also, I'm not sure what parameter resolution the software allows - it wouldn't make sense to have a frequency display if it were not possible to control it in 1Hz, 0.1Hz, whatever, increments.

These per-pad filters, they've obviously been optimized to allow the CPU to handle up to 64 of them simultaneously. They're not programmed to be as universally configurable as, say, the built-in EQ effect, which is much more CPU intensive, hence the limit of only 2 effects.



also, the real-time display you're proposing - that would be incredibly CPU-intensive, I'd imagine. The processor would actually have to run through all of the filter calculations that it normally does in real-time during playback, but somehow much faster than real-time for a feasible "real-time" display.

sciguy wrote:Why not? Here's a few thoughts:

thanks a lot sciguy.

sciguy wrote:How would the UI deal with the exponential scale of frequency?

althought I'm no programmer, I am sure, it is easy ( my deep thought ).

sciguy wrote: It wouldn't make sense just to have a linear mapping, where one click of the data wheel does a one hertz increment.

sciguy wrote:Also, it's completely possible that the filter algorithm doesn't actually ever deal with a literal frequency value. In fact, probably likely. It's a sort of arbitrary scaling that doesn't necessarily make the most sense in the coding for a digital filter. So that 0-100 number, that might be more related to the "actual value"—the process happening—than a frequency.

sciguy wrote:Also, I'm not sure what parameter resolution the software allows -

easily 1hz, ( my mathematical thought. )

sciguy wrote: it wouldn't make sense to have a frequency display if it were not possible to control it in 1Hz, 0.1Hz, whatever, increments.

it´s possible. 1 hz it´s sure and 0.1, whatever, increments.... maybe too.

sciguy wrote:These per-pad filters, they've obviously been optimized to allow the CPU to handle up to 64 of them simultaneously. They're not programmed to be as universally configurable as, say, the built-in EQ effect, which is much more CPU intensive, hence the limit of only 2 effects.



also, the real-time display you're proposing - that would be incredibly CPU-intensive, I'd imagine. The processor would actually have to run through all of the filter calculations that it normally does in real-time during playback, but somehow much faster than real-time for a feasible "real-time" display.

in summary:

CPU intensive



Greetings sciguy,
and to all the participants here!!

sally wrote:

sciguy wrote:Why not? Here's a few thoughts:

thanks a lot sciguy.

sciguy wrote:How would the UI deal with the exponential scale of frequency?

althought I'm no programmer, I am sure, it is easy ( my deep thought ).

sciguy wrote: It wouldn't make sense just to have a linear mapping, where one click of the data wheel does a one hertz increment.

I'm just being realistic here — not from a programming standpoint, but from just a logistical standpoint. The filter would of course have to range at least from, say, 20Hz to 22KHz. With one hertz increments, that's more than twenty thousand steps to sweep the full range. Even with the shift+data wheel 10-tick increment, more than 2 thousand clicks.
Notice the EQ effects parameter deals with this by making the higher frequency bands only sweepable by 10 or whatever hertz. That works, since it's limited to that higher band, and never needs to get higher resolution at lower frequencies.
I'm just saying for usability, it would be difficult to get a good resolution across the whole range, without having to scroll miles to sweep the filter.

sally wrote:

sciguy wrote:Also, it's completely possible that the filter algorithm doesn't actually ever deal with a literal frequency value. In fact, probably likely. It's a sort of arbitrary scaling that doesn't necessarily make the most sense in the coding for a digital filter. So that 0-100 number, that might be more related to the "actual value"—the process happening—than a frequency.

Again, just being realistic. In programming, you don't deal with arbitrary decimal numbers, especially not floating point or fractional values.
Math in optimized-efficiency DSP doesn't mirror the kinds of math you'd do on paper.
For example, in the theoretical calculations for a filter, you'd refer to a decimal frequency range. In the mpc, I would guess it's somehow based in relation to the sampling frequency, since there's probably code that iterates at that rate.
I dunno, I'm just saying that a decimal frequency isn't something that would easily pop out of the current filter implementation.


Don't get me wrong, I think this would be a cool feature, I just don't think it could realistically work.
and plus, these are just my own thoughts, I don't know how exactly the mpc DSP is done, so I may or may not be correct.

sciguy wrote: Even with the shift+data wheel 10-tick increment, more than 2 thousand clicks.

Here, in this case, other way is better.

sciguy wrote:I'm just saying for usability,


it would be difficult to get a good resolution across the whole range, without having to scroll miles to sweep the filter.

you could use a knob or fader (Q-links) for this.

sciguy wrote:Math in optimized-efficiency DSP doesn't mirror the kinds of math you'd do on paper.

The math is the same.

sciguy wrote: I think this would be a cool feature, I just don't think it could realistically work.

Thanks sciguy,

Because, my quote
“As sensitive as imprecise”
is good here.

Greetings

Just use your ears, Luke!

zyguli wrote:Just use your ears, Luke!

let's see ... if you are sensible.

if you could also see (what I propose ), why go blind??? ?? ? ? .

zyguli wrote:Just use your ears, Luke!

+1

Bathmutz wrote:

zyguli wrote:Just use your ears, Luke!

+1

Excuse me one moment. Thanks!

But..

Saw you the poll ?

which OPTION you prefer?
Poll runs till 30 Jun 2013 22:32
OPTION A 60% [ 3 ]x
OPTION B 20% [ 1 ]
OPTION C 20% [ 1 ]

this parameter



make this.




16 cycles per second

not 16, just 8 (up &down)
1 bar (96ticks) / 12 = 8

Bugfix wrote: not 16, just 8 (up &down)
1 bar (96ticks) / 12 = 8

Your math is good but.... Can I see your 8 cycles/sec/44100 on display ( your screenshot ) please?

THX bugfix!!! See you later...

I don't have to I still see 8 on there.. it's just totally asymetric, lopsided waveform. Take a sample which does not have 100% positive amplitude as a starter.. and you're set.

Bugfix wrote:I still see 8 on there..

I see 16

Bugfix wrote:it's just totally asymetric,
lopsided waveform.

here no photoshop on my part, man...

ohh yes this is how it work (jjos).

sally wrote:

Bugfix wrote: not 16, just 8 (up &down)
1 bar (96ticks) / 12 = 8

Your math was good here, but.... Can I see your 8 cycles/sec/44100 on display ( your screenshot ) please?

THX bugfix!!! See you later...

C´mon bugfix...
you know
os2 can adjust rate at 0.01 ( lfo ) too.

then, you say?!
96 ticks / 1 = 96 (waveform) ?


NO
the waveform is not seen with 96 as you might say in this exercise/example. ...



Greetings!!

sally wrote:the waveform is not seen with 96 as you might say in this exercise/example. ...

..so what it might be Sherlock..

tell you what, rate 4.00 stands for "per one bar", rate 1.00 "per quarter" period..

now take a look what's the number below rate 1.00? my mp shows 0.95

that makes me no wonder "hmmmmmmm"

Look now, you feed your sampler with extraordinary samples expecting it will calculate all good? ..common..