Great. I really am sorry that I can’t offer more assistance on this at the moment but you seem to be flying through it!
Bézier Curves for Gentables
Yeah, but that’s because I’m taking some shortcuts. We’ll probably have to redo it some day.
What do you think of something like this? I had to override the virtual paint function inside HandleViewer. Do you think that’s fine? I’ll probably need to add a bool too to check whether it’s a quadbezier gentable or not.
EDIT: Fixed some things with the latest commit.
Looks great. I don’t think it’s a problem to override that method. You’re not doing any filling so it shouldn’t have an effect on other tables. You may check how it looks when using tables which are stacked on top of each other.
This is the second incarnation of a table editor for Cabbage. Please feel free to push it to the limits. No doubt we will need to rewrite it at some point in the future!
It may be a while before the next release of Csound which means users will not be able to try this out. Or we could add your opcode source to Cabbage and use one of the API load opcode functions to load the opcode on start up. That should work fine and give users access to the new feature straight away.
We could try this when the code is ready.
I’ve coded a new opcode called getfargs. It works at init-time, but I think I’ll change it to work with k-variables instead. My idea is to have invisible texteditors in Cabbage and replace their text() with the table arguments. That way .snaps will save the data.
getfargs.zip (620 Bytes)
Sounds good. Most table opcodes in Csound use ft(function table) rather than just an f, so perhaps getftargs might be a better fit? Do we also need an opcode that will automatically create a table based on an arg string?
I’ll change it. I think we can use scoreline to create the table. Or are you thinking about something else?
True, I’d forgotten about that. That should do the trick nicely.
I did some work today on the develop branch, but it should be pretty simple to merge your changes. I can prepare a Windows versions that can make use of Victor’s latest API methods, but not for OSX. On Linux it’s not really a problem as building there is not that tricky. OSX is not too hard but I’m happy to keep using Victor’s packages. He does some linking when he’s building that I’ve no interest in emulating. But, he has offered to run off an OSX build from the latest Csound source for another project I’m involved in, so that will give us up to date builds for both Windows and OSX. Once you’re happy that everything is working Ok I’m glad to merge the changes.
I think you can merge right now because the basic functionality is already there. I’m somewhat busy at the moment so I’ll be wrapping it up in small chunks whenever I have some free time. I hope I didn’t break anything!
The things that are missing or not working are:
- Maybe, a way to set the color of CtrlPoints and straight line CtrlPoints from inside the .csd. Right now I’m picking it automatically like this:
handles[i]->setColour(colour.withRotatedHue(0.3f)); // Straight lines CtrlPoints. - The method for figuring out if a straight line has been formed is accurate but not perfect.
- The popup that shows the coordinates when you position the mouse over a point is not displaying the right data.
- The “quadbezier” gen routine needs an error-handling function.
- The getftargs opcode would be better as a k-rate opcode and I mostly guessed how to write it. I’ll probably have to ask in the developer’s list if I’m not breaking anything.
The only thing to note if you merge is that people in Linux will have to build Csound-develop in order to build Cabbage-develop because -at least in Ubuntu- the official packages for Csound are old. (what happened to @Codesound).
I’ll try merging and see how it goes. I might wrap the new API calls in an #ifdef for now so that people don’t have to upgrade to build from the dev branch. We can continue to work on it in the meantime, but can remove the bezier branch.
I’ve fixed the coordinates in the popup bubbles. I have the fix inside an “if (genRoutine==Quadbezier)”. I don’t know if it shouldn’t be a general fix instead because I tried the GEN07 example and when you have a handle with y=0 it displays 0.7 or something like that. But I didn’t want to touch it in case you had a reason for doing it like that.
I did something better regarding this, but it is still accurate/not-perfect. I don’t see an simple solution because depending on the size and MinMax of your f-table the quantization makes it impossible to create a true straight line. I mean for example, sometimes a straight line requires a ctrlPoint with y=91 but with the mouse you can only drag the handle to 90 or 92. Anyway, as a musician I don’t think this is really a big issue.
I’ll work with the opcodes next.
The popup bubbles are tricky because we are converting from one resolution to the next. But I’m happy for you to dig around for a solution. Everything can be improved 
I haven’t merged the changes yet. But there is no hurry I suppose. I did update the JUCE source yesterday. It looks to have fixed all those file browser issues on Linux. I push it through the to dev branch. I’d be very happy to see the last of those issues!
Hey Rory,
I was wondering if you were planning on merging the branches anytime soon. I hope to have some time this weekend to write the man pages for the new GEN routine and the getftargs opcode.
Cheers.
I can try merging this week. I’ll let you know.
Hi @gsenna, I’m just wondering about how best to do this. Have you contributed those opcodes to Csound? If we merge now we will get stuck because the only people with access to that version of Csound will be those who build it themselves. On Linux this is fine. And I guess on Windows it’s Ok too as I can build there. But I’ll probably have to if-def stuff on OSX to stop any errors? What do you think?
Oh, yes. I forgot about that. The Opcodes are in the develop branch of Csound and I’m about to send the man pages and some comments on copyrights and references to the list. With that in place I think you should wait until v6.08 is released and then try to merge. What do you think?
Right now I’m trying to find a way of solving the dynamic-size issue in the getftargs Opcode, but John said something like it was OK to use a fixed size for the moment.
We can probably merge and have it ready to go before the next release. But there is no rush as many won’t be able to use it until they update. I think a lot of opcodes use a fixed p-field size. I don’t think it’s much of a problem considering very little space is allocated.
Yes, I think that’s fine.
I ended up doing “argcnt_of_ftable * (width_of_snprintf + decimal_dot + space) + \0”. It still wastes some space, but at least it grows or shrink according to argcnt. There is probably a C technique for allocating dynamic arrays with dynamic size that I’m missing.
You’d need a linked list I think. I remember Victor got us to program one in C when I was a student of his. It nearly drove me mad. Thank God for std::vector!
I’ve come across that term in my search. Maybe I’ll try to implement a new version to test and learn how it works. And indeed, thank god for all the containers in the std and for smart pointers for dynamic memory. Amen!