Developer forum
I know there was talks at some point to create a developer forum/channel. I think it would be a good idea so that we can share publicly.
Any other agree?
Yan
PS: I might have some exciting news to share....
Any other agree?
Yan
PS: I might have some exciting news to share....
I'm at work and I'm just wondering if the exciting news you wanted to share can be found here?
https://pongasoft.com/vst/SAM-SPL64.html#release-notes
I really wish I wasn't at work because I want to try this out like now
Is it ok I posted this?...I'll delete it if I'm spoiling surprises.
Edit: Didn't realise this has been out for ages. Well...that can only mean some other sort of exciting news
Last edited by MrFigg on 19 May 2020, edited 1 time in total.
🗲 2ॐ ᛉ
I absolutly agree. And i would love to see some GIT OSS where we can contribute. I am way to busy and on the other hand to stupid and lazy to finish a project, but i would like to contribute here and there. I just thought, why the hell Murf doesnt made his stuff OSS on GIT? Ok, dont get me wrong, its the decision for everybody themselfs and nobody to blame or claim, just a thought...
Reason12, Win10
I'd pay for private lessons in programming for audio/vst. Developers forum sounds great.
M
M
Ok I guess I will give a teaser....
And this is a major breakthrough (at least as far as I am concerned ):
* plugin is built with CMake entirely!!!
* loads in CLion natively and can generate Xcode project as well (since it is cmake based)
* in dev mode (= local build in Recon) can use loguru (DLOG_F, DCHECK_F...)
* can start Recon from CLion in debug mode and step through the code
More to come...
Yan
And this is a major breakthrough (at least as far as I am concerned ):
* plugin is built with CMake entirely!!!
* loads in CLion natively and can generate Xcode project as well (since it is cmake based)
* in dev mode (= local build in Recon) can use loguru (DLOG_F, DCHECK_F...)
* can start Recon from CLion in debug mode and step through the code
More to come...
Yan
That's interesting. Which Jukebox SDK version is that based on?
Not for me, unfortunately, I'm on Windows, using plain text editor and Jukebox 4.0. There is a working source-level debugger in Visual Studio, but I don't use it (because "Real Programmers dont ..." ).
It is based on the only publicly available one at this time (4.1.0) although it should be possible to do something similar with previous versions... It is currently working for macOS only but this is very early and my plan is to have it work on Win10 as well... and much much more....
Yan
- meowsqueak
- RE Developer
- Posts: 50
- Joined: 21 Jan 2015
This is... excellent! Let me help test it, please...
Awesome stuff Yan!
Ha! Was just about to "ping" you to check this out…
Selig Audio, LLC
-
- Posts: 23
- Joined: 30 May 2018
I just wanted to add my vote for a developer forum. I've just started trying to code my own RE (literally yesterday) and I'd love a dedicated place for discussion and to get help. I'm a web developer by trade so I'm a half decent coder but I haven't written any C++ for 20 years. That said, I'm pleasantly surprised that the SDK examples are building without any issue using the "get started" instructions so I'm feeling encouraged. In one afternoon I've managed to make my own modified GUI based on one of the examples, get that built and see it inside Recon. My plan is to start with a player or something without any serious DSP (I don't have the knowledge) and see how I get on. I'm not likely to make a world-beating synth or effect but I might be able to make some fun MIDI-processing tools or a step sequencer!
Curious about the debugging tools inside CLion, that's the IDE I'm using. I love JetBrains stuff, been using their IDEs for years.
Curious about the debugging tools inside CLion, that's the IDE I'm using. I love JetBrains stuff, been using their IDEs for years.
-
- Posts: 23
- Joined: 30 May 2018
This is a call for help from fellow RE devs! Just getting started and having some trouble with custom displays.
I'm trying to create a simple pattern display that shows 16 steps as 30x30 pixel filled squares with a brighter colour for the "on" steps. It seems to me that the dimensions of the custom display in device_2D.lua have to be defined with the high-res sizes that are 5x the actual pixel display size so I create a custom display that is 200 in height. In my custom draw function in display.lua I code as if the display is 40px in height (which it is according to my on-screen ruler app). If I then draw a rect with the draw_rect() function with top=5, bottom=35 then I expect to get a rect that is 30px in height with a 5px border top and bottom. But this doesn't seem to work as I have a smaller gap at the top than the bottom so it doesn't look vertically centered.
I'm looking at other players like Quad Note, Evolution etc and I'm assuming that they're using the primitive drawing functions to do these displays rather that using image-based widgets. Can anyone help with what I might be doing wrong? The maths seems like it should be simple but the outcome is definitely off! I must be having some fundamental misunderstanding about the custom graphics co-ordinates are working.
I'm trying to create a simple pattern display that shows 16 steps as 30x30 pixel filled squares with a brighter colour for the "on" steps. It seems to me that the dimensions of the custom display in device_2D.lua have to be defined with the high-res sizes that are 5x the actual pixel display size so I create a custom display that is 200 in height. In my custom draw function in display.lua I code as if the display is 40px in height (which it is according to my on-screen ruler app). If I then draw a rect with the draw_rect() function with top=5, bottom=35 then I expect to get a rect that is 30px in height with a 5px border top and bottom. But this doesn't seem to work as I have a smaller gap at the top than the bottom so it doesn't look vertically centered.
I'm looking at other players like Quad Note, Evolution etc and I'm assuming that they're using the primitive drawing functions to do these displays rather that using image-based widgets. Can anyone help with what I might be doing wrong? The maths seems like it should be simple but the outcome is definitely off! I must be having some fundamental misunderstanding about the custom graphics co-ordinates are working.
How do you define "virtual" display dimensions in hdgui_2D.lua? (See https://developer.reasonstudios.com/doc ... om_display)tallrobphilp wrote: ↑25 May 2020This is a call for help from fellow RE devs! Just getting started and having some trouble with custom displays.
I'm trying to create a simple pattern display that shows 16 steps as 30x30 pixel filled squares with a brighter colour for the "on" steps. It seems to me that the dimensions of the custom display in device_2D.lua have to be defined with the high-res sizes that are 5x the actual pixel display size so I create a custom display that is 200 in height. In my custom draw function in display.lua I code as if the display is 40px in height (which it is according to my on-screen ruler app). If I then draw a rect with the draw_rect() function with top=5, bottom=35 then I expect to get a rect that is 30px in height with a 5px border top and bottom. But this doesn't seem to work as I have a smaller gap at the top than the bottom so it doesn't look vertically centered.
I'm looking at other players like Quad Note, Evolution etc and I'm assuming that they're using the primitive drawing functions to do these displays rather that using image-based widgets. Can anyone help with what I might be doing wrong? The maths seems like it should be simple but the outcome is definitely off! I must be having some fundamental misunderstanding about the custom graphics co-ordinates are working.
These are coordinates in which drawing is done.
-
- Posts: 23
- Joined: 30 May 2018
Thanks so much. I'd changed my dimensions in device_2D.lua and I forgot to update them in hdgui_2d.lua as well so some sort of conversion/stretching was happening. Now that the numbers all match up it looks fine. Must pay more attention. This is why we need a dedicated developer forum, I can't be the only beginner fumbling my way through!orthodox wrote: ↑25 May 2020How do you define "virtual" display dimensions in hdgui_2D.lua? (See https://developer.reasonstudios.com/doc ... om_display)
These are coordinates in which drawing is done.
There is actually a working developer forum at RS where you can get help: https://www.reasonstudios.com/forum/for ... y.php?f=31 (you have to be logged in at the RS site first). But it does not fit well for general developer discussions.tallrobphilp wrote: ↑25 May 2020Thanks so much. I'd changed my dimensions in device_2D.lua and I forgot to update them in hdgui_2d.lua as well so some sort of conversion/stretching was happening. Now that the numbers all match up it looks fine. Must pay more attention. This is why we need a dedicated developer forum, I can't be the only beginner fumbling my way through!
It is also very limited in terms of usage and functionalities. It feels like using a program from the 90s. Almost impossible to post a screenshot, etc...orthodox wrote: ↑25 May 2020There is actually a working developer forum at RS where you can get help: https://www.reasonstudios.com/forum/for ... y.php?f=31 (you have to be logged in at the RS site first). But it does not fit well for general developer discussions.
Yan
-
- Posts: 23
- Joined: 30 May 2018
Thanks for the pointer towards the other forum. It doesn't seem very active but I'll definitely have a poke around and see what I can find.
I've hit my next brick wall - I can't work out how to get sequencer play position (PPQ) so I can update my RE interface (a custom display) with some sort of indication of where the playback head is. I'm just trying to build a simple 16-step sequencer player device. I spent a couple of hours poking in the online docs this afternoon and after trying a couple of things (and failing) I'm wondering if I need to calculate the information I need within the realtime C++ code and then send it back to the motherboard so I can store as a custom property which can then be read by my custom display rendering function.
Am I on the right track?! I don't seem to be able to "subscribe" to the playback position and other built-in properties to trigger redraw, only to my custom properties.
I've hit my next brick wall - I can't work out how to get sequencer play position (PPQ) so I can update my RE interface (a custom display) with some sort of indication of where the playback head is. I'm just trying to build a simple 16-step sequencer player device. I spent a couple of hours poking in the online docs this afternoon and after trying a couple of things (and failing) I'm wondering if I need to calculate the information I need within the realtime C++ code and then send it back to the motherboard so I can store as a custom property which can then be read by my custom display rendering function.
Am I on the right track?! I don't seem to be able to "subscribe" to the playback position and other built-in properties to trigger redraw, only to my custom properties.
-
- RE Developer
- Posts: 128
- Joined: 14 Nov 2018
Yes, that's what you need to do. Read the playback position in the realtime code and store it in a different property that is owned by the realtime code. You can then add that "messenger property" to the custom display. By the way: You don't need to update it every batch as the display isn't updated that often. Update it 25-30 times per second and you're good.tallrobphilp wrote: ↑25 May 2020I'm wondering if I need to calculate the information I need within the realtime C++ code and then send it back to the motherboard so I can store as a custom property which can then be read by my custom display rendering function.
Am I on the right track?! I don't seem to be able to "subscribe" to the playback position and other built-in properties to trigger redraw, only to my custom properties.
By the way: I'm fairly active here and on the developer forum at reasonstudios.com. If you need help feel free to PM me.
-
- Posts: 23
- Joined: 30 May 2018
Thanks for the offer of help, I may well get in touch in the future! I've now got my sequencer playhead working by feeding back the play position from C++ back to the motherboard. Pleasantly surprised at how much progress I've made in a few afternoon's worth of coding having never done any real plugin coding, C++ or Lua.ForgottenClank wrote: ↑25 May 2020Yes, that's what you need to do. Read the playback position in the realtime code and store it in a different property that is owned by the realtime code. You can then add that "messenger property" to the custom display. By the way: You don't need to update it every batch as the display isn't updated that often. Update it 25-30 times per second and you're good.tallrobphilp wrote: ↑25 May 2020I'm wondering if I need to calculate the information I need within the realtime C++ code and then send it back to the motherboard so I can store as a custom property which can then be read by my custom display rendering function.
Am I on the right track?! I don't seem to be able to "subscribe" to the playback position and other built-in properties to trigger redraw, only to my custom properties.
By the way: I'm fairly active here and on the developer forum at reasonstudios.com. If you need help feel free to PM me.
I am very happy so say that what I set to do is working even better than I thought it would...
Build is driven 100% from cmake whether it being a local build (use native compiler with string, etc...) or local45/universal45 builds (cmake invokes sdk tool chain after generating the expected directory structure and files required by it). This includes invoking render2D from cmake as well (so invoked only when changes happen). Build happen 100% OUTSIDE the source tree (so no more polluting the source tree...). Source of truth is cmake (list of files/included dir declared in cmake is injected in build45.py). Local build is (screaming) fast because only compiles what changes... Both Makefile generator or Xcode generator work great.
Note that I would like to make it work on PC as well (right now it is only macOS). If you are interested in helping please contact me especially if you are familiar with cmake.
Will be released open source in the near future...
Yan
Build is driven 100% from cmake whether it being a local build (use native compiler with string, etc...) or local45/universal45 builds (cmake invokes sdk tool chain after generating the expected directory structure and files required by it). This includes invoking render2D from cmake as well (so invoked only when changes happen). Build happen 100% OUTSIDE the source tree (so no more polluting the source tree...). Source of truth is cmake (list of files/included dir declared in cmake is injected in build45.py). Local build is (screaming) fast because only compiles what changes... Both Makefile generator or Xcode generator work great.
Note that I would like to make it work on PC as well (right now it is only macOS). If you are interested in helping please contact me especially if you are familiar with cmake.
Will be released open source in the near future...
Yan
Fantastic Yan
Some more progress... CMake build in CLion on Windows10!
Yan
Yan
-
- Information
-
Who is online
Users browsing this forum: No registered users and 94 guests