Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'break' on non-multiple of 8 offsets leaves garbage data #2

Open
amj opened this issue Oct 11, 2016 · 3 comments
Open

'break' on non-multiple of 8 offsets leaves garbage data #2

amj opened this issue Oct 11, 2016 · 3 comments

Comments

@amj
Copy link
Contributor

@amj amj commented Oct 11, 2016

according to the spec as i understand it, the bulk-update commands that operate on 8x8 blocks can pass along x,y offsets that aren't actually multiples of 8. Right now, untz_monome will break if it sees those, leaving the remaining serial bytes specifying the data left in the buffer.

So, any 'break' in that switch statement can potentially leave junk in the incoming serial stream to foul up the next command.

this is based on my reading of http://monome.org/docs/serial.txt, which seems a little obtuse, but hey.

@TheKitty
Copy link
Owner

@TheKitty TheKitty commented Oct 11, 2016

I tried to decipher the functions from multiple documents. The company
doesn't have much incentive for people to make home grown sequencers. So
yes, until I get a working, communicating version, testing each function
will be very hard unless the docs are clear

On Tue, Oct 11, 2016 at 9:27 AM, Andrew Jackson notifications@github.com
wrote:

according to the spec as i understand it, the bulk-update commands that
operate on 8x8 blocks can pass along x,y offsets that aren't actually
multiples of 8. Right now, untz_monome will break if it sees those, leaving
the remaining serial bytes specifying the data left in the buffer.

So, any 'break' in that switch statement can potentially leave junk in the
incoming serial stream to foul up the next command.

this is based on my reading of http://monome.org/docs/serial.txt, which
seems a little obtuse, but hey.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2, or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0scOEw4_E1X0hfZojUUDKJH8Zk7F_Xks5qyzpkgaJpZM4KTUkQ
.

@amj
Copy link
Contributor Author

@amj amj commented Oct 11, 2016

Yeah, i'll try patching serialosc to give me some logging to find out what's going on! I got a reply from tehn in the forum though, so i'm hopeful! :)

@TheKitty
Copy link
Owner

@TheKitty TheKitty commented Oct 11, 2016

Awesome, great work

On Tue, Oct 11, 2016 at 7:27 PM, Andrew Jackson notifications@github.com
wrote:

Yeah, i'll try patching serialosc to give me some logging to find out
what's going on! I got a reply from tehn in the forum though, so i'm
hopeful! :)


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0scHWLEm9YUeCAAano2Uawc8NdLbfPks5qy8b5gaJpZM4KTUkQ
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants