PV_ ugens, correct idioms for cookiecutter plugin template?

Development Server plugins
1

PV_UGens in the source have a particular idiom: PV_GET_BUF etc.

The cookiecutter template seems to invalidate much of this usage, and I’m too much of a C++ idiot to see my way through.

[ 25%] Building CXX object CMakeFiles/PV_FreezeMerge_scsynth.dir/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp.o
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:8:24: error: ‘ft’ was declared ‘extern’ and later ‘static’ [-fpermissive]
    8 | static InterfaceTable* ft;
      |                        ^~
In file included from /home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:5:
/home/dlm/share/superc/include/plugin_interface/FFT_UGens.h:153:24: note: previous declaration of ‘ft’
  153 | extern InterfaceTable* ft;
      |                        ^~
In file included from /home/dlm/share/superc/include/plugin_interface/SC_PlugIn.h:25,
                 from /home/dlm/share/superc/include/plugin_interface/SC_PlugIn.hpp:25,
                 from /home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:4:
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp: In constructor ‘PV_FreezeMerge::PV_FreezeMerge::PV_FreezeMerge()’:
/home/dlm/share/superc/include/plugin_interface/SC_Unit.h:68:21: error: ‘unit’ was not declared in this scope; did you mean ‘Unit’?
   68 | #define OUT(index) (unit->mOutBuf[index])
      |                     ^~~~
/home/dlm/share/superc/include/plugin_interface/Unroll.h:133:19: note: in expansion of macro ‘OUT’
  133 | #define ZOUT0(i) (OUT(i)[0]) // get first sample
      |                   ^~~
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:14:9: note: in expansion of macro ‘ZOUT0’
   14 |         ZOUT0(0) = ZIN0(0);
      |         ^~~~~
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp: At global scope:
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:22:1: error: redefinition of ‘PV_FreezeMerge::PV_FreezeMerge::PV_FreezeMerge()’
   22 | PV_FreezeMerge::PV_FreezeMerge() {
      | ^~~~~~~~~~~~~~
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:12:1: note: ‘PV_FreezeMerge::PV_FreezeMerge::PV_FreezeMerge()’ previously defined here
   12 | PV_FreezeMerge::PV_FreezeMerge() {
      | ^~~~~~~~~~~~~~
In file included from /home/dlm/share/superc/include/plugin_interface/SC_PlugIn.h:25,
                 from /home/dlm/share/superc/include/plugin_interface/SC_PlugIn.hpp:25,
                 from /home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:4:
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp: In member function ‘void PV_FreezeMerge::PV_FreezeMerge::next(int)’:
/home/dlm/share/superc/include/plugin_interface/SC_Unit.h:67:20: error: ‘unit’ was not declared in this scope; did you mean ‘Unit’?
   67 | #define IN(index) (unit->mInBuf[index])
      |                    ^~~~
/home/dlm/share/superc/include/plugin_interface/Unroll.h:129:18: note: in expansion of macro ‘IN’
  129 | #define ZIN0(i) (IN(i)[0]) // get first sample
      |                  ^~
/home/dlm/share/superc/include/plugin_interface/FFT_UGens.h:81:21: note: in expansion of macro ‘ZIN0’
   81 |     float fbufnum = ZIN0(0);                                                                                           \
      |                     ^~~~
/home/dlm/share/tools/pvfreeze2/pv_freezemerge/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp:29:9: note: in expansion of macro ‘PV_GET_BUF’
   29 |         PV_GET_BUF
      |         ^~~~~~~~~~
gmake[2]: *** [CMakeFiles/PV_FreezeMerge_scsynth.dir/build.make:76: CMakeFiles/PV_FreezeMerge_scsynth.dir/plugins/PV_FreezeMerge/PV_FreezeMerge.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:85: CMakeFiles/PV_FreezeMerge_scsynth.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2

Edit: If all else fails, I can get sorta what I wanted without making a new plugin. But I was really hoping to put some IIR decay logic into the pv freeze framework, so I’d rather not give up just yet.

TIA for advice,
hjh

2

I’m not sure this helps, but when I made the BufFFT library, I seemed to have stuck to the old C++98 conventions:

I remember having similar issues. I’m sure it could be worked around.

Sam

3

I see. Then maybe I’ll just hack a first version into my sc3-plugins repository and if I come up with anything releasable, deal with the code style later.

hjh

4

As it happens, I’m getting some fantastic sounds from reconceiving PV_Freeze’s freeze parameter as a 0 to 1 coefficient rather than a binary switch. So (if @josh approves of lifting chunks of his code) I guess I’d better figure out how to package it, since sc3-plugins is de-facto frozen.

hjh

5 Likes
5

That sounds fffaaaaabbbb!

1 Like
6

The ideal thing would be for us to make a new SC3 Plugins Collection. I think I could get this together…maybe some time next year. There are so many good ones just floating in the ether.

Sam

2 Likes
7

I’m not sure whether decentralizing, or re-centralizing into another large repository, is better. More recent plug-ins that are not in a central repository are harder for users to find – I’m hooked on the PortedPlugins’ analog modeling filters – haven’t dug into the Mutable Instruments clones – I’ve got the oversampling oscillators but tbh haven’t integrated it into my work yet – etc etc.

In any case, lacking guidance for new-code-style PV plug-ins, I guess I’ll use your BufFFT as a template.

And it sounds even better now that I’ve fixed the phase instability in the middle freeze range :wink:

I’m also thinking to do a bin-based envelope follower.

hjh

8

BTW @Sam_Pluta sorry to bother, but I’m having some trouble moving the code over from the sc3-plugins wrapper into a modified BufFFT repository.

The code in sc3-plugins is calling the next function only when a frame needs to be calculated.

The code in the BufFFT-cribbed repository is getting called with a wrong buffer number – FFT output should be either bufnum or -1, but a debugging printf says:

numbins = 1023, buf = 1024  (yes)
numbins = -1, buf = 0       (no no no)

Everything is defined in terms of PV_Unit and I can’t find a significant difference between the version that I hacked up in JoshPVUGens and the new repo.

(I know you’re not responsible for maintaining other people’s appropriation of your repository structure – just wondering if this is anything you had run into while developing BufFFT.)

TIA –
hjh

9

Or, opening up the question to anyone: I can prove with debugging posts that FFT_next is setting its output to -1, and my PV_Freezish_next is immediately reading 0.0 from the same location.

>> FFT_next, pos = 64
<< FFT out = -1.000000
ZIN0(0) = -1.000000
>> FFT_next, pos = 128
<< FFT out = -1.000000
ZIN0(0) = -1.000000
>> FFT_next, pos = 192
<< FFT out = -1.000000
ZIN0(0) = -1.000000
>> FFT_next, pos = 256
<< FFT out = -1.000000
ZIN0(0) = -1.000000
>> FFT_next, pos = 320
<< FFT out = -1.000000
ZIN0(0) = -1.000000
>> FFT_next, pos = 384
<< FFT out = -1.000000
ZIN0(0) = -1.000000
>> FFT_next, pos = 448
<< FFT out = -1.000000
ZIN0(0) = -1.000000
>> FFT_next, pos = 512
<< FFT out = 1024.000000
ZIN0(0) = 1024.000000
numbins = 1023, buf = 1024, m_stage = 0
>> FFT_next, pos = 64
<< FFT out = -1.000000
ZIN0(0) = 0.000000                         WHAT...?
numbins = -1, buf = 0, m_stage = 1

And this doesn’t happen when I run what seems like the same code, but compiled in a different project.

sigh C…

~~

EDIT: Never mind, I found it. PV_ units shouldn’t “DefinePVUnit” – they should “DefineDtorUnit” – that was the only difference between the working and broken versions, and correcting this did fix the crash.

~~

hjh