Hey, new member here!
Just wanted to announce two projects:
oLvgui : https://github.com/GModal/oLvgui
oLvosc : https://github.com/GModal/oLvosc
It's GUI & OSC libraries to make networked OSC controllers for musical performance...and it runs on LÖVE.
video:
https://youtu.be/nw84JxDqqa0
oLvgui is a table-based GUI for LÖVE, and oLvosc is an OSC (Open Sound Control) module for Lua and LÖVE (>=11.3). Both OSC modules are written with Lua only (no C or C++). It's currently only a subset of OSC, but I'm working on it...
oLvosc also works with pure Lua (>=5.3), but there's an additional module for a threaded blocking OSC server that's LÖVE-only.
Why another GUI? I had some specific needs:
- Responsive for OSC musical performance controllers (buttons that work on mouse-down)
- a GUI that's on-the-fly interpreted, and easily modified during use
- has a 'knob' control element
- works on mobile devices and the Linux desktop.
At this point it's only been tested in Linux and Android. The GUI is nothing fancy, but works for my needs. I'm sure it's a bit of a hack...
The GUI could easily work for other things besides OSC controllers.
The demos (.love files) include:
- OSC controller for Ardour
- OSC message monitor
- color picker and theme editor
- 'tina', a concertina-like instrument for mobile
- various control demos
The GUI .love demos are here:
https://github.com/GModal/oLvgui/tree/main/demo_love
and the source is here:
https://github.com/GModal/oLvgui/tree/main/demo_src
- A demo of oLvgui interacting with pd2jack, where the mobile control surface directs pd2jack to load a Pd patch, and the patch itself sends commands back to the control surface, with instructions to build the GUI. It's in the video, but not yet in the repository (not sure if it should be in oLv or pd2jack repos).
There are also Lua console-only demos (OSC) in the oLvosc repository.
oLv: Music-oriented GUI and OSC libraries
- BrotSagtMist
- Party member
- Posts: 613
- Joined: Fri Aug 06, 2021 10:30 pm
Re: oLv: Music-oriented GUI and OSC libraries
Thats actually a pretty neat gui system.
At least it doesnt gobble 100% cpu like these other libs do.
Text looks blurry at same places, you better check if you render to full integers everywhere.
What i learned from my own gui and seeing that you already placed shadows under elements: Add a text shadow.
Doesnt look like much on a phone screen but on big ones its kickass and really that little extra that makes users of traditional toolkits jealous.
At least it doesnt gobble 100% cpu like these other libs do.
Text looks blurry at same places, you better check if you render to full integers everywhere.
What i learned from my own gui and seeing that you already placed shadows under elements: Add a text shadow.
Doesnt look like much on a phone screen but on big ones its kickass and really that little extra that makes users of traditional toolkits jealous.
obey
Re: oLv: Music-oriented GUI and OSC libraries
Hey, thanks! Adding dropshadows for text is a good idea. I'll try it!BrotSagtMist wrote: ↑Thu Jul 28, 2022 12:09 am Thats actually a pretty neat gui system.
At least it doesnt gobble 100% cpu like these other libs do.
Text looks blurry at same places, you better check if you render to full integers everywhere.
What i learned from my own gui and seeing that you already placed shadows under elements: Add a text shadow.
Doesnt look like much on a phone screen but on big ones its kickass and really that little extra that makes users of traditional toolkits jealous.
The whole gui is always scaled with an api call (love.graphics.scale() & mouse/touch is scaled as well), it's a really simple way to do it. So no doubt the text can get a little blurry (especially if it's scaled down). If the defined working window is the same as the target device, the scale factors are 1:1, though.
And that's if oLvgui.autoscale() is called. If not, the scale is 1:1. The factors can be changed manually too.
- BrotSagtMist
- Party member
- Posts: 613
- Joined: Fri Aug 06, 2021 10:30 pm
Re: oLv: Music-oriented GUI and OSC libraries
I dont think scaling elements that are supposed to be sharp is a good idea anyway.
You can probably get around this by multiplicating the factor while drawing.
I use floats to render elements and the screen is described from 0 to 1, so button(0.5) will always lead to the button rendered in the center regardless of screensize.
Note that Löve internally works with percentual fractions, from -1 to 1, and not pixels.
So a render is made with X/windowsize*scale-shift.
Taking the steps out and just using X-shift alone always leads to sharp boxes that perfectly scale with the window size with zero overhead.
Sorry for derailing, thats how i would do it, but i also like breaking löve convention.
If you want others to use this lib, following the standard löve way has its benefits too.
You can probably get around this by multiplicating the factor while drawing.
I use floats to render elements and the screen is described from 0 to 1, so button(0.5) will always lead to the button rendered in the center regardless of screensize.
Note that Löve internally works with percentual fractions, from -1 to 1, and not pixels.
So a render is made with X/windowsize*scale-shift.
Taking the steps out and just using X-shift alone always leads to sharp boxes that perfectly scale with the window size with zero overhead.
Sorry for derailing, thats how i would do it, but i also like breaking löve convention.
If you want others to use this lib, following the standard löve way has its benefits too.
obey
Re: oLv: Music-oriented GUI and OSC libraries
Thanks, BrotSagtMist, this input is very helpful.
I gotta say: here, I'm not seeing much (if any) fuzzyness on any of the elements. I'm using three different devices (phone, small-ish tablet, big-ish tablet) and everything looks pretty sharp. The original size/proportions for the GUI match the small tablet, and none of the devices share the same aspect ratio.
The call to love.graphics.scale() is done once every love.draw() cycle, and always before any rendering. So no elements are drawn and then scaled.
Could it be it serendipity? The scale factors for the devices playing well with the scaling algorithm? Possibly. More feedback from others would be good.
Some very annoying aspects of scaling are difficult to avoid. With a non-proportional scale, boxes look fine, but knobs - not so much.
Also I should mention that oLvgui.autoscale() only works if it's running on a mobile device (Android). The scale factors can still be adjusted manually, elsewhere.
I gotta say: here, I'm not seeing much (if any) fuzzyness on any of the elements. I'm using three different devices (phone, small-ish tablet, big-ish tablet) and everything looks pretty sharp. The original size/proportions for the GUI match the small tablet, and none of the devices share the same aspect ratio.
The call to love.graphics.scale() is done once every love.draw() cycle, and always before any rendering. So no elements are drawn and then scaled.
Could it be it serendipity? The scale factors for the devices playing well with the scaling algorithm? Possibly. More feedback from others would be good.
Some very annoying aspects of scaling are difficult to avoid. With a non-proportional scale, boxes look fine, but knobs - not so much.
Also I should mention that oLvgui.autoscale() only works if it's running on a mobile device (Android). The scale factors can still be adjusted manually, elsewhere.
Re: oLv: Music-oriented GUI and OSC libraries
BrotSagtMist, I did remove the scale() call when the factors are 1:1. I can't seem to see a difference.
Can't hurt, though.
Can't hurt, though.
- BrotSagtMist
- Party member
- Posts: 613
- Joined: Fri Aug 06, 2021 10:30 pm
Re: oLv: Music-oriented GUI and OSC libraries
Well this is the most prominent spot: ![Image](http://www.enlightenment.org/ss/e-62e2f73cef6b92.42851891.png)
Can you explain why it looks different?
![Image](http://www.enlightenment.org/ss/e-62e2f73cef6b92.42851891.png)
Can you explain why it looks different?
obey
Re: oLv: Music-oriented GUI and OSC libraries
No, I can't. I actually don't know what level of anti-aliasing to expect from the engine. If that's considered bad, it's the same without the scale() call.
Shouldn't be anything fancy happening. There's a love.graphics.translate() call in the drawknob(), but that, like most every draw func, is within graphics state push() and pop() calls.
Some elements have an explicit # of segments, which is probably not necessary.
Shouldn't be anything fancy happening. There's a love.graphics.translate() call in the drawknob(), but that, like most every draw func, is within graphics state push() and pop() calls.
Some elements have an explicit # of segments, which is probably not necessary.
Re: oLv: Music-oriented GUI and OSC libraries
Is the centered text maybe drawn like this: love.graphics.print(text, x-textWidth/2, y)
If textWidth is odd you'll draw at non-integer coords, if x is an int.
If textWidth is odd you'll draw at non-integer coords, if x is an int.
Tools: Hot Particles, LuaPreprocess, InputField, (more) Games: Momento Temporis
"If each mistake being made is a new one, then progress is being made."
"If each mistake being made is a new one, then progress is being made."
- BrotSagtMist
- Party member
- Posts: 613
- Joined: Fri Aug 06, 2021 10:30 pm
Re: oLv: Music-oriented GUI and OSC libraries
I tried
And its gone, yea youre not using integers there. Rendering to floats will cause a blur.
Text on the knob is still blurry tho.
Code: Select all
local oldprint=love.graphics.print
love.graphics.print= function(text, x, y, r , sx, sy, ox, oy, kx, ky ) print(text,x,y) oldprint(text, math.floor(x),math.floor(y), r, sx, sy, ox, oy, kx, ky) end
Text on the knob is still blurry tho.
obey
Who is online
Users browsing this forum: No registered users and 23 guests