Forum Replies Created
-
Posts
-
Dank je Baus 🙂 But all credits go to Dnaldoog. This is just me enhancing the panel to my own likes.
About your question. I think it should work. It’s not entitled to one kind of synthesizer, it just sends and fetches the midi signal from/ to a memoryBlock. Right Dnaldoog? You can try it with the panel he attached to his post a few posts earlier.
To Dnaldoog:
I was just wondering if the record and dump request buttons needed to be separate. Wouldn’t it make sense to Record straight away and do the dump request by pressing just one button? Maybe put a little delay with a timer on the “Dump Request” to make sure all data is being recorded?Just another mockup with some changes to the gui. And a more detailed Sysex Manager. Stil listboxes. Too late to work on a custom component right now.
Just a quick mockup. Might as well make a custom component so I can make editable headers of what the Sysex actually does and to be able to load sysex from disk to send as a request. Now it’s done with a listBox. But it’s a start.
I must buy a new pair of glasses. Misread the “load Sysex to Panel”. I thought that it was to load from the synth. But that’s what the record button is for. Yay me. Maybe reword it to “Load Sysex from PC”. But that is an easy fix I can do myself.
There is always room for improvement. I can send different requests to the synth but my aging brain has a hard time remembering al those Sysex requests. Soooo, a Sysex request command “Manager” would be awesome :P.
No, just kidding. Seems like a challenge I might take on myself.
@ Goodweather:
Well, the branches and history thing is actually a Github thing. But basically it comes down to this: The Master Branch is usually the one that should be compiled to get a working version. Other branches are to try out code or to make changes outside of the Master Branch, test them.. and when it’s working they could be merged in the master Branch. So, when working with different people or different ideas for changes, that’s as many branches you can have. Every time a change is made, there is also a history being created to make it easier to revert back to some older version.
What’s happening here is that the “Master Branch” is version 6.0 but the “Stable Branch” is also version 6.0. So this led to some confusion on my side on how to get version 5.3 and preferably the updated (or rather said, downgraded) version without VST2. I think I got it and here are the steps to get it:
Go to the CTRLR repository on Github. You’ll see it’s the Master Branch and underneath it says that the last commit Roman made was CMake: initial Cmake import. Further to the right, there’s 726405f (I guess this is a history number from Github) dated January 28, and there are a total of 526 commits.
— Click on Master and change it to Stable (The number of commits in the blue bar changes to 577).
— Click on the “577 commits”. It will open a page with all commits that were made during the development of Ctrlr.
— Scroll down and click on older to go further back in history.
— Then scroll down to June 14, 2018. Which says: Removing VST SDK due to Steiberg takedown (click the dots at the end, couldn’t agree more).
— To see the code from that date, click at <> next to the version number dee3e52.There you have it. June 14, 2018. And when you click the green Code button, you can download the commit from that date as a zip file to do things locally. This has Ctrlr file version 5.3\0 (Ctrlr/Builds/VisualStudio2017/resource.sc). But this is without the VST SDK. Now when you go back to Commits (or history), on August 31 2018 it says “VST3 support Added”. But this is Ctrlr file version 6.0. Maybe Roman’s reasoning behind it was that it was some sort of new version to build from. But I think I need to go for one commit later, the “6.0 version bump”. I don’t know.. argh..
I guess I’m going to try to compile the latter one.
@Possemo:
Newer versions of JUCE bring new classes or other functionality, besides the bug fixes. Backward compatibility isn’t always guaranteed. So, yes, better be careful with that. But where Goodweather wants some minor bugfixes and add some definitions, I want to see whether it’s doable to bind an already existing class to LUA. If that’s working.. maybe add some more classes. And so on.The VisualStudio version shouldn’t make that much of a difference as far as I know. They should be backward compatible to compile Ctrlr. And in Ctrlr version 6.0 there is a VisualStudio2019 which should give a headstart. I hope.
I bet Roman is laughing his ass off reading this 😉
Busy with some things in another thread/ post so I can’t tell whether it’s working or not. But I see the opportunities for my own panel. Never got around saving Sysex to the pc but it’s more clear now looking at the LUA code. Is it possible to enhance the panel to load Sysex from a file from the pc as well, to upload it to the synth? I should be able to overcome the limited number of presets then.
Great work!!
Because 5.3.201 is the stable version, I thought it was indeed better to start with that version and go from there. But there’s some confusion about how to get that version from GitHub.
There are different branches. Master, stable, lua bind cleanup and testing. I can see they differ from each other because of missing commits but I can’t download a different branch. It’s only the master branch that has a download. And there are tagged versions of which 5.3 (not 5.3.201) is one of them. But that one is from 2014 (?). (Would explain the use of VS 2013) Those tagged versions have downloads as a zip file. But somewhere around 2018, when Steinberg dropped support for vst2, an updated version for Ctrlr was released. I can see some files were deleted and changes were made.. but no branch or tagged version to download.
AFAIK the Juce version is an old version that is being downloaded. Already downloaded boost and tried to follow the instructions for compiling the GitHub repository. But I get errors that go way above my pay grade.. so far no luck.
Hope Goodweather has more luck..
There is an old thread about the stdafx.cpp file..
Sorry, thought you were trying to compile CTRLR for Mac os, but I see you were talking about an old post. I thought I might give it a go as well to try to compile CTRLR. For your information.. I’m using visual studio 2019. At installation, I only selected the “c++ for desktop” and made sure the windows SDK 10 was selected. (I needed it for JUCE to compile, that’s working. Doesn’t necessarily mean it works out of the box for CTRLR.)
The JUCE Library is downloaded when you download the CTRLR repository. You can see an older (this is 5.1.1 whereas JUCE is now at version 6.01) version of JUCE in the conveniently named JUCE folder.
Ok, after some messing around. When I download the CTRLR repository, there’s only a visual studio 2017 sln file. But when I download the stable CTRLR branch, there is a visual studio 2019 sln file. Both throw errors about a stdafx.cpp which I didnt’get around yet. There’s a mention about it at the CTRLR github under compiling for windows, but I do not understand what it is saying:
“You need to set the creation of the precompiled header for the stdafx.cpp.”
To compile it, at the top there is a x64 debug, with next to it “select startup item”. I’m wondering why I can’t choose x64 release instead of debug. I select ctrlr.exe for startup item. No dice either. So.. that’s as much as I can help you for now.
Sorry, double post. Forgot to add that you can compile it by going to the “build” folder and choose the right OS and program which you want to compile with.
Wouldn’t it be easier to install something like VMware and an image of Mac os instead of going for the cross-compile route? To my knowledge code::blocks works better on osx than it does on windows. Because on windows, visual studio seems to be the way to do it. And that way, you can even test it.
On the ctrlr GitHub, there are some hints how to compile it for different operating systems.
I’m trying to get my head around Juce to see if it’s doable to add classes to ctrlr. Better start at the source, right? I do the recompiling with visual studio community (free) with a free Juce and with some effort was able to build a small GUI.
Wanted to recompile the ctrlr repository this week (3 week’s vacation) to do the same like you want to do.
Do you want to switch banks and then show the according presets? Presets for drum sounds or patterns?
It would help if you could provide more information than you did. Is there a midi or sysex implementation? Do you already have some code?
Not familiar with the MPC software but I can see it’s acting like a daw. There are too many variables but I think we can pin this down to an issue with the midi connection.
Possemo made an excellent manual about what the culprits/ downsides are connecting a vst to certain DAWs. https://ctrlr.org/forums/topic/oberheim-matrix-1k-ctrlr-vst-ableton-10-live/#post-118784
Thank him kindly for taking the time to write it all down. Now go see if it works..
The openDevice error means the MPC software can’t reach the synth you want to control?
Scroll down to goodweather’s reply.
Getting there. See animated gif.
Lots of things to finetune. Also need to get the velocity bar at the bottom to work. Make it switch velocities on mousedown according to the note that is selected. But getting there.
Thank you all.
The Zipfile method is used in the Render demo panel. You can find it in the Ctrlr folder under panels/ demo/ Render. If you open it, select SVG in the test type combobox. The SVG’s you see then are in the icon.zip, imported in the resources tab. See the createSVGdrawable script for the rest.
Ok, after giving Possemo and dnaldoog’s advice some thoughts. I think it’s a better idea to separate the Sysex and the building of the rectangles in the arpeggiator. It should mean some rewriting of the code but that is not a big deal. Dnaldoog gave me a headstart.
In other words, thank you for the advice.
Appreciate the work you put into this Dnaldoog. Funny thing is, I already wrote most of the code like you did but “with” the scrolling part. I never got the IMG to work so I did it all with painting.
The thing I’m not doing (yet) is creating rectangles on the fly because I wanted to avoid the inserting and deleting values in tables.
It’s hard to explain the way I do it now and I promise to send you a mail later with the panel. But I discovered a major f*ck up. I discovered ctrlr overwrote my old save while I thought it was saving to a new version.
Actually it is. Even I’m opening arpbuild4.. when I save it, it says it’s saving to arpbuild3. Great.. give me some time to rewrite some code and I’ll send you the new version later.
Why not generate the renctangles on the fly according to the mouse position?
Because there is no viewport class imported to ctrlr (There is one in juce though.), I need to do some trickery to create the sense of a viewport.
So when I scroll up or down, all coordinates for the black and white lines are read from a table. Later, the Sysex is being read and paints the rectangles. Because the Sysex are 16 different MemoryBlocks, one for each note, I’m even able to do the repaint per note instead of repainting the whole component.
Elegant? Maybe not. There is indeed a lot of calculation going on in the background. Lots of if else then statements on the mouse events. Lots of getByte and setByte. Lots of repaint. But it is almost working as intended.
With the Rectangle class being up to date or a viewport class, it could have been more elegant but unfortunately that isn’t the case. No Biggie but it means a lot more code than needed, yes.
Gonna give your code a try now, Dnaldoog. You’ll hear from me soon.
I’m going to try the code you gave Dnaldoog. Looks promising. I swear I found the _G[] thing in some old forum posts from human fly but I got the wrong syntax doing _G[block ..i.. ], without the ” “. So close, argh.
Just one question. Is it possible to do the same to the g:setBounds() or g:fillRect() ? Like _G[“block” ..i]:setBounds() ?
I could try this myself. Was just wondering :). But thank you already. Like so many times before.
