PG8X (inspired by the JX8P): new beta version uploaded

[caonoize]

OK. Next beta is out.

Now running 32bit version under Wine/fsthost:

Me likey!

[martin_l]

Questions to all MAC 10.8 users:

I got a report that the 64-bit VST plugin does not show up in Ableton nor in Bitwig on Mac 10.8.
Can anybody confirm that this is the case? Or is there anybody who can use it on that system?

Thanks!
Martin

Update: The problem is solved. It was due to permissions. Here is the trick:

If PG8X is not showing up in the host, try to create an empty textfile "pg8x.ini" in the same directory in which PG8Xl.vst or PG8X.dll resides.

Cheers,
Martin

[Yeager]

Hi Martin,

Love the synth, BUT I still have something that is bothering me.
I think someone called it voice allocation or something like that.
What happens is that when you load my example preset,(see below, called Wrong.zip) the first time you play 5 or 6 different notes there is a big thunk (DC related ?) with every new note.
After that all is well, except when you then change the num of voices in the settings menu It all starts again.
You can see what I mean by using fi. S(m)exoscope, or the free MOscilloscope.
Just play 6 notes, change the num of voices and play 6 notes etc. And it looks like this (the first note I played was about 3/4 up the scope) :

[iae41610]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

many thanks for this great project!!
will test the sysex/ctl mapper-workflow
PG8X <-> mks70 (rom v3.xx) + pg-800

----------------------------
SuperJX_NRPN
Midi CC description
http://www.vecoven.com/superjx/download ... X_NRPN.pdf (http://www.vecoven.com/superjx/downloads/files/SuperJX_NRPN.pdf)

[PAK]

Martin, just a minor observation about PG8X's automation handling. I don't know if it's been mentioned previously, so sorry if it has..

PG8X is using 0-99 for its own display, but it's actually reporting 0 - 1.00 to the host. In other words, the "real" resolution, which both the mouse and any hardware uses, is 101 steps. As that's one step more than the on-screen 100 values it means sometimes PG-8X's GUI isn't consistent with the host.

IE type 0.02 or 0.03 into Cubase and both values will show as 03 on the PG8X display. You can also use the mouse input and have the PG8X GUI generate 0.71 in the host automation lane but show 73 on the display etc.

I first noticed this stuff because a hardware rotary encoder was set to 100 steps (to match the onscreen controls) and was skipping some values even though the host automation was reporting all input correctly.

I'm also not sure if the hardware map issues might be getting complicated by a certain part of PG8X's code expecting 7 bit values in order to round things to 0-99 onscreen? Anyway, the result is regular 7-bit notched rotaries need 28 "phantom steps" inserted (even when used via automation based controllers) since 128 values are required in order to generate the whole (0-99) range.

Minor issues, but small niceties which would help hardware mapping and host consistency if they can be fixed.

Small feature request too - if the function midi/settings buttons could be exposed to host automation/MIDI, it would allow for mouse free operation of the GUI

[EvilDragon]

Host automation actually has much more steps than 101. It's a floating point value from 0.0 to 1.0, 32-bit variable (IIRC).

[martin_l]

Hi Martin,

Love the synth, BUT I still have something that is bothering me.
I think someone called it voice allocation or something like that.
What happens is that when you load my example preset,(see below, called Wrong.zip) the first time you play 5 or 6 different notes there is a big thunk (DC related ?) with every new note.
After that all is well, except when you then change the num of voices in the settings menu It all starts again.
You can see what I mean by using fi. S(m)exoscope, or the free MOscilloscope.
Just play 6 notes, change the num of voices and play 6 notes etc. And it looks like this (the first note I played was about 3/4 up the scope) :

Will investigate...

Martin

[martin_l]

Martin, just a minor observation about PG8X's automation handling. I don't know if it's been mentioned previously, so sorry if it has..

PG8X is using 0-99 for its own display, but it's actually reporting 0 - 1.00 to the host. In other words, the "real" resolution, which both the mouse and any hardware uses, is 101 steps. As that's one step more than the on-screen 100 values it means sometimes PG-8X's GUI isn't consistent with the host.

IE type 0.02 or 0.03 into Cubase and both values will show as 03 on the PG8X display. You can also use the mouse input and have the PG8X GUI generate 0.71 in the host automation lane but show 73 on the display etc.

I first noticed this stuff because a hardware rotary encoder was set to 100 steps (to match the onscreen controls) and was skipping some values even though the host automation was reporting all input correctly.

I'm also not sure if the hardware map issues might be getting complicated by a certain part of PG8X's code expecting 7 bit values in order to round things to 0-99 onscreen? Anyway, the result is regular 7-bit notched rotaries need 28 "phantom steps" inserted (even when used via automation based controllers) since 128 values are required in order to generate the whole (0-99) range.

Minor issues, but small niceties which would help hardware mapping and host consistency if they can be fixed.

Small feature request too - if the function midi/settings buttons could be exposed to host automation/MIDI, it would allow for mouse free operation of the GUI

It should all be consistent. The automation data is always FLOATING POINT data, i.e not limited to 101 steps. Sysex data is, indeed 0-127, but I checked carefully that the mapping of display values and sysex values is the same as in the hardware.

Yes, the internal resolution of the plugin is more than 0-99 or 0-127. Parameters are stored as floating point values, and only rounded for display and sysex. You should be able to hear changes in the filter cutoff (for instance) when using fine control (shift+mouse) before you see a change in the display.


Cheers,
Martin

[wald]

After learning Midi to a slider it crashes if I send Midi to that slider. Takes down the whole host (haven't seen that in years...)
Latest Beta VST on Mac. Happens on: Live, Maschine, Logic (all 64 bit). Midi data was sent from Novation Remote 37 SL.

[martin_l]

After learning Midi to a slider it crashes if I send Midi to that slider. Takes down the whole host (haven't seen that in years...)
Latest Beta VST on Mac. Happens on: Live, Maschine, Logic (all 64 bit). Midi data was sent from Novation Remote 37 SL.

Which Midi data are you trying to learn? CC? NRPM? Could you give me some more details, as I am currently not able to reproduce the problem.

Thanks,
Martin

[PAK]

Host automation actually has much more steps than 101. It's a floating point value from 0.0 to 1.0, 32-bit variable (IIRC).

Yes, that's right. But these are two different things Along with the internal processing resolution of the engine, the plugin has to report the controls automation range visible in the hosts automation lane.

For example, Diva reports its cutoff range as 30.00-150.00 to the host. This means Cubase can edit the filter automation lane with 12,000 steps of precision. More typically a plugin will use 0.00-100.00, or 10,000 steps, which is what Monark/Reaktor, uses. By contrast PG8X reports 0.00-1.00 (100 steps, or 101 if you include zero). So, even though the plugin itself is processing internally at a higher resolution, the resolution actually accessible from the host's automation GUI is limited because of what the plugin is telling it.

In PG8X's case the resolution is less than 7 bit, which is very low. It doesn't mean the engine itself is using 100 points. But it does mean that, for example, if you discovered a harmonic sweet spot at 89.75 (between 89 and 90), you can't use the automation lane to have the engine stay at that point, you'll only hear the engine move past it on its way from 89 to 90, since entering a value of 89.75 will be rounded up to 90. This is why most plugins report a higher value like 100.00 (10,000) rather than 1.00 (100).

You can often get around these display limitations with hardware control. But here PG8X throws an additional complication..

With most plugins, if they reported 101 steps for a controls range, it will scale the automation input correctly to what the plugin shows. With PG8X this doesn't happen. It skips values, partly due to reporting 101 values but using 100 on-screen, and partly because it appears it might be coded on the assumption that it will only ever see 7 bit values coming at it from hardware.

This gives a less pleasant hardware mapping experience, especially with notched rotaries as they must include some "phantom" values, requiring them to send 128 values rather than the expected 100 (or 101 if you're going with what's actually reported to hosts like Cubase). It's a common issue for standard MIDI, but that is not typical of how a plugin responds to host automation. It means host automation controllers can normally work around the "phantom steps" issue. However PG8X doesn't allow that due to the way it's handling the automation input it sees..

Part of the problem is world+dog is only using 7 bit MIDI, and automation based control (esp via hardware) is not being tested so issues go unnoticed.

Anyway, this stuff is basically cosmetic, though it will impact the resolution accessible by presets you store (as explained in the 89.75 example, where entering that will be rounded to 90, because of the way PG8X reports the resolution to the host presently.. )

TLDR: It'd be nice if Martin would at least increase the value presented in the host automation lane from the present 1.00, to the 100.00 more typical of many plugins, if nothing else

[martin_l]

Host automation actually has much more steps than 101. It's a floating point value from 0.0 to 1.0, 32-bit variable (IIRC).

Yes, that's right. But these are two different things Along with the internal processing resolution of the engine, the plugin has to report the controls automation range visible in the hosts automation lane.

For example, Diva reports its cutoff range as 30.00-150.00 to the host. This means Cubase can edit the filter automation lane with 12,000 steps of precision. More typically a plugin will use 0.00-100.00, or 10,000 steps, which is what Monark/Reaktor, uses. By contrast PG8X reports 0.00-1.00 (100 steps, or 101 if you include zero). So, even though the plugin itself is processing internally at a higher resolution, the resolution actually accessible from the host's automation GUI is limited because of what the plugin is telling it.

In PG8X's case the resolution is less than 7 bit, which is very low. It doesn't mean the engine itself is using 100 points. But it does mean that, for example, if you discovered a harmonic sweet spot at 89.75 (between 89 and 90), you can't use the automation lane to have the engine stay at that point, you'll only hear the engine move past it on its way from 89 to 90, since entering a value of 89.75 will be rounded up to 90. This is why most plugins report a higher value like 100.00 (10,000) rather than 1.00 (100).

You can often get around these display limitations with hardware control. But here PG8X throws an additional complication..

With most plugins, if they reported 101 steps for a controls range, it will scale the automation input correctly to what the plugin shows. With PG8X this doesn't happen. It skips values, partly due to reporting 101 values but using 100 on-screen, and partly because it appears it might be coded on the assumption that it will only ever see 7 bit values coming at it from hardware.

This gives a less pleasant hardware mapping experience, especially with notched rotaries as they must include some "phantom" values, requiring them to send 128 values rather than the expected 100 (or 101 if you're going with what's actually reported to hosts like Cubase). It's a common issue for standard MIDI, but that is not typical of how a plugin responds to host automation. It means host automation controllers can normally work around the "phantom steps" issue. However PG8X doesn't allow that due to the way it's handling the automation input it sees..

Part of the problem is world+dog is only using 7 bit MIDI, and automation based control (esp via hardware) is not being tested so issues go unnoticed.

Anyway, this stuff is basically cosmetic, though it will impact the resolution accessible by presets you store (as explained in the 89.75 example, where entering that will be rounded to 90, because of the way PG8X reports the resolution to the host presently.. )

TLDR: It'd be nice if Martin would at least increase the value presented in the host automation lane from the present 1.00, to the 100.00 more typical of many plugins, if nothing else

OK. I am a bit surprised Cubase does not allow you to define a automation value with higher accuracy, but limits to 0.01 steps. In reaper, I can edit every point, and give whatever value, e.g. 0.5128, if needed.

I don't see any problem with hardware controllers. In fact I checked that every of the 128 Midi values is reproduced correctly.

That said, there is no problem to change the values reported to the host. I just checked that old projects with automation still load correctly. In fact, the host internally always uses the 0.0-1.0 range. The displayed values are only scaled to what the plugin suggests as display scale.

Now, the question remains, whether to report the 0.0 - 100.0 as suggested by you, or whether to report 0-99 to the host, which gives a better representation. But, note that even that would not be an exact match. In the hardware JX-8P, you can hear that there are still changes to the sound, even if the display is not changing. They went (for cost reasons, I guess) for the display format 0-99 (integer) but internally use higher resolution. The conversion to the 0-99 display range in the hardware is not quite linear. It seems the hardware uses a lookup table to translate the 0-127 MIDI range to the 0-99 display range.

The most consistent would probably the 0.0-99.0 range.

Cheers,
Martin

[PAK]

OK. I am a bit surprised Cubase does not allow you to define a automation value with higher accuracy, but limits to 0.01 steps. In reaper, I can edit every point, and give whatever value, e.g. 0.5128, if needed.

Automation is one of those things Cubase never seems to get around to overhauling, despite all the new features etc :/ Hardware in Cubase can pass higher accuracy values to a plugin, and you can even see this in plugins which display their own higher precision values internally. But the Cubase automation lane is stuck with the limitation..

Edit: Btw, the decimal point setting can be changed. EG Roland's Aira plugins use no decimal point, and report 0-256 in Cubase. Ever consistent, Steinberg's own plugins, like HALion 5, use a single decimal point ie 100.0 (or 1,000 values). But I don't think it can be set to use more than 2 decimal places (... ). Like most things, related to hardware and automation control over audio software, it's a bit of a mess ;(

I guess, since a dev can add resolution via the main value, rather than relying on the usage of decimal points, it's never been seen as a big issue. Especially since hardware controllers are rarely more than 7 bit anyway. But it's something many plugin devs appear unaware of..

I don't see any problem with hardware controllers. In fact I checked that every of the 128 Midi values is reproduced correctly.

Yep, you're not wrong! Sorry if sleepy posts were making things less clear. It's the expectation certain things (like Automap) have when passing data via host automation to a plugin..

Say you wanted to map a button to a control with 100 values, and each time you press the button you wanted it to step 1 value - so it goes 1,2,3 etc through 99. Right now, the PG8X GUI implementation (not the audio engine itself!) means the button must be pressed 128 times so that some of the pushes do nothing, in order for the PG8X display to generate 00 through 99 properly. Make sense?

As buttons and rotaries can generate +/-1, they can break free of the confines of MIDI and define specific custom resolutions, which are then passed via the automation controller software to the host plugins. So they're not necessarily dealing with 7 bit MIDI values.

The way a plugin interprets what Automap sends can vary depending on what values Automap sees it supporting, the number of steps in what you're trying to send (since it must then divide the amount of steps into the resolution number the plugin itself reports), and also how the plugin might handle values that Automap then sends it (rounding etc).

It's not a huge deal since it can be fixed by setting Automap to send 128 values, with the result of some phantom steps. Just more of a nice thing if it could be fixed.

Of course, you could equally apply the blame to Automap's inflexibility in such situations

Now, the question remains, whether to report the 0.0 - 100.0 as suggested by you, or whether to report 0-99 to the host, which gives a better representation

Yes it does! The recommendation wasn't meant so literally 0.00 to 99.00 would give a better representation and also allow 9,901 steps (greater than 12 bit resolution) within Cubase's host automation lane. That's more than sufficient. Any theoretical mismatch would be small enough so as not to really matter in general usage. Though if you want to stick to how the GUI code handles converting values to 0-99, perhaps a number that is a multiple of 128, which could also divide by 100 (128.00.. 12,800? )would be best for the value, as this (might) fix the issues seen in something like Automap.

[martin_l]

After learning Midi to a slider it crashes if I send Midi to that slider. Takes down the whole host (haven't seen that in years...)
Latest Beta VST on Mac. Happens on: Live, Maschine, Logic (all 64 bit). Midi data was sent from Novation Remote 37 SL.

OK. I was able to reproduce the problem. It occurs when you start learning one parameter, and then move another slider WITHOUT first clicking on WRITE VALUES / CLOSE.

I will try to fix it, i.e. prevent the host from crashing.

Current work-around. Always learn one control at a time. Right-click the slider, move the Midi controller and then click the WRITE VALUES / CLOSE button, so that the side panel returns to the standard view. Then you can repeat for another parameter without crashing the host.

Cheers,
Martin

[caonoize]

Hi Martin,

Love the synth, BUT I still have something that is bothering me.

I observed this (http://imgur.com/z1h1B2o) as well. If you have full unison, the transient offset occurs on all the voices at once. This can even be seen with the init patch. I think something's getting a bogus init on new patch load, but where is not something I can tell. Filter state?

Clues?