Forum Replies Created
-
Posts
-
No, I’m afraid I did not finish it until now. But there is still hope that it will be done in the year 2020. I was very close when I stopped working on it.
I would be interested in a working .so plugin too. I’m afrid it seems like there was never a working version ever. Well, maybe there is a special DAW which would work. It would be interesting if someone knows a DAW which works with the linux-plugin. I have only experienced different crashes with different DAW’s.
I know that dasfaker is just maintaining the site (btw. without being paid for). But he has no full control over it. He has no access to domain, provider, webspace and the like.
I could be wrong but afaik exporting instances never worked in linux. Maybe in a very early version but not in “recent” versions starting from v5.3.201. Also I never could load the .so plugin in any DAW I tried.
I believe Roman had some problems when switching from VS2010 to VS2015. It did ont build at first try. He had to make some changes in the Ctrlr code. Maybe now VS is more backward compatible than at that time but if I would try it again I would want v5.3.201 and I would try to build it with VS2010. I’s a pity that the exact state of v5.3.201 seems to be lost. If I am right the whole “look and feel” stuff got lost after v5.3.201. Though I did never use it, some important panels such as the ones from Dasfaker rely on it.
I didn’t mean that you shouldn’t implement new Juce versions. If I get it right the most important changes from different Ctrlr builds were the use of new Juce releases. THIS I think does not make a lot of sense, well it may if they fixed bugs in some Juce code but it can be counterproductive when the new Juce is not fully compatible with the Ctrlr code.
I think I remember now, that v5.3.201 was done with VS2010. Some time ago Roman made the jump from 2010 to 2015. Maybe that was the mistake I made when I tried to compile Ctrlr some years ago using VS2015. I think I should have tried VS2010. After a long time not exactly knowing what I was doing I eventually gave up.
I think it would be a good idea to start with 5.3.201 but that will probably be difficult. If I remember well it was built with vs2013. So you would have to use this version of visual studio. And you need some other things like the boost library https://www.boost.org/. Is at least v5.3.201 still available on github?
I think it does not make a lot of sense to just always upgrade to the newest version of Juce. You would have to implement the new features of Juce in Ctrlr in order to get some advantage out of the new version. An example of what I mean is the new design of the uiButton. It may be nice but it does not fit always. You would have to be able to go back to the old design. I think there is no doubt that this would be possible if implemented correctly. If this is not possible I would prefer an old version of Juce.
@Kagneeann: hmm, this is probably spam what you are posting. I could not find any MIDI interfaces at Reecoupons.
For Mac and specially for PC users I’d recommend this one:
https://www.gear4music.ch/en/G4M/ESI-MIDIMate-eX/1YDWI think you have to spend about $30 for a MIDI interface. You won’t do yourself a favor buying some rubbish half-working junk. For PC it is important that the manufacturer does provide dedicated drivers as otherwise you won’t be able to run more than one app at the same time (multi-client capabiltiy). On the other hand it is nice when you get plug-and-play with a class compliant device (on Mac even multi-client capable). The ESI Midimate EX has both advantages – it is class compliant and (if needed for multi-client capability) there are dedicated drivers for Windows.
The Midimate is a bit special in the way that there is no hard-wired MIDI-out and MIDI-in. Both Port1 and Port2 can be In or Out – it depends on how you select it in your DAW/App. That can be confusing but it should be no big problem. It works perfectly for sysex transfer and whatever MIDI message.
To be fair: the Midimate is not the only good low-cost interface. E.g. I heard nothing but good things about the small Roland MIDI-interface:
https://www.roland.com/global/products/um-one_mk2/
It’s a bit more expensive though and I’ve never tried it myself.I’d say that all these methods are equally well. Which one you choose is a matter of taste.
That’s it. It is a bit weird but after all not that complicated. It just uses msb/lsb method with 2 CC’s. A bit odd that they use the full spectrum of 2x7bits (16364 values) when they are just using 256 values of them. This is achieved by steps of 64. I added a uiFixedSlider method to dnaldoogs version. I like the fixedslider. It allows to show the positive sign, like this: +127. FixedSlider contents are done very easy with Excel. No problem making hundreds of entries in sequence.
This is indeed very strange – even stranger than I guessed.
So this is not cc17 from -127 to 0 and cc49 from 0 to +127. This looks a bit like whacky msb/lsb. Is there an explanation from Novation somewhere? Maye you were right with your “64-offset” though I don’t see the logic in doing that. Anyway, let’s guess it:[ 17] Val:[ 0] RAW:[b7 11 00]
[ 49] Val:[ 64] RAW:[b7 31 40] –> 64 = -127[ 17] Val:[ 1] RAW:[b7 11 01]
[ 49] Val:[ 0] RAW:[b7 31 00] –> 128 = -126[ 17] Val:[ 1] RAW:[b7 11 01]
[ 49] Val:[ 64] RAW:[b7 31 40] –> 192 = -125[ 17] Val:[ 2] RAW:[b7 11 02]
[ 49] Val:[ 0] RAW:[b7 31 00] –> 256 = -124[ 17] Val:[ 2] RAW:[b7 11 02]
[ 49] Val:[ 64] RAW:[b7 31 40] –> 320 = -123[ 17] Val:[ 3] RAW:[b7 11 03]
[ 49] Val:[ 0] RAW:[b7 31 00] –> 384 = -122There should be a way doing this with a uiFixedSlider and a multi midi-message. I mean, without using Lua scripts.
I guess you are talking about parameters like this:
osc1 LFO1 depth cc 28:60 -127 to 127*
Interesting, I have never seen that. I don’t see any other way than Lua scripting eiter. The script of dnaldoog should do the trick. I would have done it similar.
Btw. this has not much to do with MSB/LSB. It’s just that cc60 takes over where cc28 ends.
If you are thinking 7-bit msb/lsb that would look as follows:
0-127 = MSB 0 / LSB 0 to 127
128-255 = MSB 1 / LSB 0 to 127This may be hard to understand when using decimal notation. In binary it makes much more sense:
This is 127: 01111111 (see the 8th bit is 0 thus msb is 0)
This is 255: 11111111 (8th bit is 1)For a value up to 255 you need just 8 bits. So, if you have 7-bit lsb/msb split you will just need 1 bit for msb.
just be aware that when there are parameters in the sysex program dump which you cannot access directly you will have to:
receive the whole dump,
decode it,
edit the parameter,
encode the altered dump,
send it back to the synthThere are some panels who are doing this procedure, including my panels for the Matrix-6 / Matrix-1000 and Moog Source. If the dump is not too big it does work quite well. In the case of the microkorg program dump these are about 300 bytes. That should be “near realtime”. But this will be some coding work.
This midi implementation chart is not complete. Look at this one:
https://midi.user.camp/d/korg/micro-korg/
Many parameters are accessible just by simple CC’s.
The sysex dump format of the early digital korg synths are a pain in th *ss. It has been done on the Korg 05R/W panel. This is the same on the microkorg. MIDI-bytes only have 7 bits, computers in general normally use 8-bit bytes or a multiple thereof such as 16-bit or 32-bit “longwords”.
Korg handles this as follows: 8-bit bytes are crunched into a “worm” of 7-bit MIDI bytes.
The first MIDI byte has all the 8th bits of the following 7 bytes. Then the next “batch” of seven 8-bit bytes encoded into eight 7-bit bytes is appended, again the first byte includes all the 8th bits of the following 7 bytes. The last “batch” will be an incomplete one with the last few bytes – e.g. it just includes the last four bytes.Therefore, you have to write a Lua procedure which decodes this worm of appeded 7-byte batches into correct 8-bit bytes.
mdeca did this on his Korg 05R/W panel with pure calculation but it can also be done with the help of a tool included in Ctrlr called “BigInteger” where you can extract and set bits.The guy in the youtube video tells that msb is the “coarse” value and lsb the “fine” value. Well ok you can look at it like this. For me, e.g. “coarse tune” is a different parameter than “fine tune” – not parts of one value. But that may be a matter of taste. Btw. a 14-bit value has 16364 values, that’s right. It goes from 0 to 16363. That’s why I mentioned 16363. Never forget that 0 is not nothing – it is a value as well.
In the deprecated panels section there were examples of how to draw envelopes. Even with mouse-drag capability. Somehow they got lost. Here they are – attached to this post.
NRPN 99/98 is not coarse/fine setting but msb and lsb part of ONE value – the controller number. You have to understand that msb and lsb are two parts of one value broken into two bit-pieces. E.g. 11111110000000 is a 14-Bit value. You can break this into msb (in this case 1111111) and lsb (in this case 0000000).
CC,ByteValue,MSB7bitValue,99,-2
CC,ByteValue,LSB7bitValue,98,-2
CC,ByteValue,LSB7bitValue,6,-1This is a NRPN “multi” message in Ctrlr. -2 corresponds to the MIDI controller number. It can be as big as 16363 (a 14-bit value) broken into two 7-bit nibbles.
Sysex does work similar. Use MS and LS for 7-bit nibbles and ms and ls for 4-bit nibbles. So a sysex message could look like this:
F0 42 3g 58 B0 63 04 B0 62 08 B0 ms ls F7
Why not generate the renctangles on the fly according to the mouse position? You have to query the mouse position anyway, don’t you? Instead of selecting a predefined rectangle when a mouse x and y is within a specific range, just draw the rectangle. You will have to calculate x and y – well I don’t know but I guess there must be an elegant way to do this. Hmm, ok when I look at your pictures you probably want to be able to shift the rectangles when you move to higher or lower note range… and you will have to be able to clear them when you click an already drawn rectangle again.. quite some coding work. Well yes, maybe it is easier to predefine all rectangles. It will be interesting to see if this works.
I don’t see exactly what you want to do. Why do you want to add =Rectangle() to the variable? Couldn’t you do something like i=Rectangle() and i being Block1 to Block512?
Edit: no of course that won’t work either… Maybe if we now exactly what you want to do then it would be easier to make some suggestions. E.g. when you draw some graphics, do you use the uiCustomComponent? Probably. You would need to set coordinates for the rectangle otherwise they will all draw over themselves. Or do you use a dedicated uiCustomComponent for each rectangle? Probably not, that would make the panel too complex.
I do have a theory. Maybe it is completely wrong, I don’t know anything about Roman. It’s just that it would make sense to me:
It could be that Roman thought about selling Ctrlr one day. That is, when it would be mature enough to release a final version. Many projects are open source at the beginning and then they eventually get bought by a big enterprise and are then sold commercially. The idea could have been “kinda commercial” and thus he allowed selling panels from the beginning. Unfortunately that never happened until now, but who knows – hope dies last.
