search

wednesdayayay / Scrawl

standalone Raspberry Pi shape generator/positioner/painter
GNU General Public License v3.0
51 stars 2 forks source link

Drawing area is offset by 50% on display #3

Open TubularCorpration opened 4 years ago

TubularCorpration commented 4 years ago

Hi,

I just set up Scrawl in a RPi 3b+ using your latest ISO and everything starts up fine, but after loading the actual drawing area is off center, so that the lower right corner is in the center of the display and as a result only the lower right quadrant of it is actually visible (in the attached image, the red square is the drawing area and the blue square is the display). Console and the splash screen are completely normal

I've tried changing the overscan values in the config file and it affects the splash screen during startup but there's no change once Scrawl is actually running.

TubularCorpration commented 4 years ago

https://i.imgur.com/V5QafEG.png

TubularCorpration commented 4 years ago

Some clarification - this is only happening when I try to control the brush location with MIDI CC when no mouse is attached. The mouse works normally as long as no CC is sent. If I send any CC data for either axis while a mouse is connected, the paintberush doesn't move in accordacne with the CC calue sent, but DOES immediately become offset from the mouse cursor position by half the screen resolution on both axes (negative on the Y and positive on the X, so that in the linked image, if the mouse cursor is in the quadrant of the display shown in purple, the paintbrush is in the quadrant diagonally opposite, and if the cursor is in any of the quadrants shown in blue, the paintbrush is no longer on the screen).

The ultimate goal is to run Scrawl with no mouse or keyboard, and use CC LFOs to modulate some of the basic controls (brush size, position, color, visibility, and a few other things) to generatively draw simple patterns I can use to seed feedback in mixers and auto_waaave.

wednesdayayay commented 4 years ago

you know that actually makes sense. I've had some drawing to screen issues when doing the auto drawing stuff and I figured I just set something wrong along the way.

Your goal sounds like my own and one of the reasons I wanted to make scrawl in the first place.

I think a quick fix would be adding a control/option to take out the mouse control. That wouldn't address the wrong draw area though.

Weird question perhaps but do you have a keyboard attached to the Pi? I've had an issue with some midi response and the draw fill when clicking via the mouse to erase if I don't have a keyboard plugged in for some reason.

I think I am going to start digging back into scrawl and try to do a rewrite from the ground up now that I know a little more than before.

I have taken a little break from programming to work more on the video side of things but am ready to start integrating Scrawl into everything.

If I can get back in and figure out what is wrong (screen&draw) I'll just make a version that doesn't use mouse and keyboard input to upload here for people who don't need it.

There are still a couple draw modes to be explored that have to do with slit scanning that make for some really interesting textures.

Thank you for reaching out!

TubularCorpration commented 4 years ago

Hey, sorry it took me so long to reply. I only have one pi to share between Scrawl and spectral_mesh right now so I've been using it with spectral_mesh for now.

I didn't ahve anything attached to the pi except for one of thos esimple Roland USB-MIDI interface cables, no keyboard and I only plugged in the mouse after I made the first post here, to see if it was affected too.

The other thing I didn't mention is that the way the brush position responds to MIDI CC seems to be inverted - as the CC value increases the brush moves left and that's kind of counterintuitive for manual drawing, becuase as I turn the knob to the right the brush moves left and vice versa.

I haven't tried it with a nanokontrol, but I don't know why it would be any different unless the profile you use to test it has the range of the control you assigned X to inverted too.

Anyway, whenever you do have a chance to work on it more let me know on scanlines.xyz if I can help with testing.

Oh, and just putting it down here so I don't forget, one other thing that could be cool in the future (unless it's already in there and I missed it) is an alpha decay, so whatever was being painted could be set to fade out (maybe in 10 millisecond intervals, so CC value 0 would give normal behavior and CC 127 would give 12.7 sec. decay time, seems like a useful range and easiest to implement, but I'm not a programmer so I don't really know). That would be especially good for keying over other sources, so that everything that got drawn would always fade back to the key color and the background source wouldn't get covered up completely.