Gentable x-axis (fixed)

[iainmccurdy]

gentableXAxis1.csd (685 Bytes) gentableXAxis2.csd (510 Bytes)
I find getting gentable to render an x-axis for any sort of a bipolar function table a bit of a negotiation. In the first attached example three tables are created:

i_	ftgen	1, 0, 8192, 10,1
i_	ftgen	2, 0, 16384, 10,1
i_	ftgen	3, 0, 4096, 7, -1, 4096, 1

The first one renders fine.
The second one, because of the increased table size, renders as if is unipolar. A horizontal scrollbar is also created inspite of zoom(-1) being requested. It seems that some sort of limit is crossed after 8192.
The third table should also be rendered as bipolar but is rendered as unipolar.
Here’s what it all looks like:

A far from ideal workaround for the third table is to create it using the form of table 1 and then overwrite it using the desired GEN07 shape in an instrument (shown in example 2).

[rorywalsh]

I can explain the second one. 163843 is the max size for a table to be drawn this way. I should change my test so that it’s 16384. When a table gets bigger than this I switch to using a native drawing routine that renders the tables much faster. It’s the same one I use for drawing waveforms. So if users try to constantly update really long tables, Cabbage will use the quicker drawing method. I can increase the table size if you wish? I thought 16384 would be Ok, but I didn’t realise it was more like 16383.

The scrollbar is again a result of the different drawing method. When working with sound files I find I usually do need a scrollbar, but I will sort that too. I will look into the last issue too. Something ain’t right there.

[iainmccurdy]

So this ties in with the mechanism that enables drawing of GEN02, GEN05 and GEN07 tables, as mentioned in the manual entry. I was sort of aware of all of this from an earlier discussion but I thought I’d clarify. The manual does say “less or equal to 16384” so I suppose it should be changed to “less than 16384”.

It’s a pity that the native method doesn’t render an x axis and it’s a pity it insists on drawing a redundant scroll-bar. Do you think it may be worth allowing the user to also manually choose the method? I appreciate that the first method will grind to a halt if huge tables are being updated every k-cycle, and I understand the usefulness of making the switch built-in and transparent to simplify the user experience, but if I wanted to change a large table only occasionally it might be nice to have the choice, what do you think? It could be a 3-way switch: 1=auto(as it is now) 2=small table method 3=large table method. If the identifier was left out it could default to the current mechanism.

At the moment I want to draw transfer functions for waveshaping (normally bipolar) which I like to create with large size tables for fidelity. The way around this that I generally use is to have two function table versions of the same shape: a small version for viewing and a larger version for use by the waveshaper, maybe I should content myself with this method.

[rorywalsh]

The manual does say “less or equal to 16384” so I suppose it should be changed to “less than 16384”.

I think I’ll leave the manual as it, as simply increase the size. Considering that 16384 is already a power of two size, it’s best to support it.

It’s a pity that the native method doesn’t render an x axis and it’s a pity it insists on drawing a redundant scroll-bar.

I’ll fix both of these issue.

It could be a 3-way switch: 1=auto(as it is now) 2=small table method 3=large table method. If the identifier was left out it could default to the current mechanism.

I can add an identifier for this. (I think, I’d have to look at the source). What should we call it?

The way around this that I generally use is to have two function table versions of the same shape: a small version for viewing and a larger version for use by the waveshaper, maybe I should content myself with this method.

This is how I would tend to approach this too, if I was constantly updating the table or even once a second. But in your case it should be pretty safe to use a larger table size.

[iainmccurdy]

If it is possible to fix the two things I mentioned in regard to larger tables then I don’t think there is really a need for any other changes…?

But it might still be desirable to make use of the ‘fill’ under the curve that is implemented with small tables with larger tables.

[rorywalsh]

Ok. I can also just increase the max table size to 44100 and explain in the manual that it’s generally a no-no to use such large tables if you are going to be updated all the time. That would suffice or? I’m just going to sort those other issues now.

[edit] if I increase the table size to 44100, then there might not be any need to actually draw the x-axis as it will not be seen in most cases?

[rorywalsh]

This is how they render now.

What do you think? There was very little work involved here. I feel like I’ve cheated somehow?!

[iainmccurdy]

Looks good.

Very little work? I wouldn’t look a gift horse in the mouth.

Thanks. I think the third table fix is an important one.