MDN 7/24/2015

I have finished full screen feature today, I might play with CSS a little bit more while working on the next feature which is changing diagrams layout.

Josh Leverette's picture

Initial offset data!

I have attached a chart created from real-time on-MCU analysis of the 9-axis data to calculate current positional offset. I was piping every 75th absolute offset value over the serial terminal so I could create this chart while trying to balance loss of data from piping data over serial versus resolution of the chart. The chart was created in Excel, of course. So, the position of the device was being sample every 47ms, give or take. Right now, the algorithm is still in desperate need of some fixes that will increase its accuracy, and I have some ideas about those fixes, but I believed showing this raw output would be pretty interesting, nonetheless. There is some crazy drift on the X-axis, and I'm not sure what that's all about. I moved the device laterally by about a meter and returned it to roughly its initial position while these samples were being taken. The Z-axis, oddly enough, actually seems to align with the motion I made pretty solidly, and the Y-axis kinda does. The X-axis seems to have no bearing on reality though in this data.

Still, very interesting! I feel like I've actually made a lot of progress now.

Offset vs Sample

Vaibhav Sharma's picture

GSOC project progress

Today worked on cross checking my code with one of the papers from where i was following the whole methodology. The feature extraction method the authors of the papers used was Local binary pattern but while using the same method i could not see any difference in my accuracy.I also worked on my MATLAB codes and added examples to them.

MDN 7/23/2015

I have finished coding the related_content button and switched to full screen feature. This feature will allow users to view one or two diagrams using full screen size which is necessary with large diagrams (SVGs). I am working on configuring a jQuery library for modal overlay div (the library is already included); also I need to create a separate style sheet for full screen.

Josh Leverette's picture


Tonight I spent some time documenting and commenting things further, along with updating READMEs and the like. I believe the LSM9DS0 driver's simplicity is a key strength, and I hope others will find it and make use of it for projects, but even now I feel like the documentation on that isn't as complete as I would like it to be.


  • Clarified some of the documentation that I had written yesterday.

Tomorrow: work on the getting started guide.

MuseScore 23/07/2015: MIDI Actions #3

Now I understand how the current implementation of MIDI Actions work.

Every Instrument has a list of MIDI Actions, every MIDI Action is a list of MIDI events (defined in instruments.xml). Also every Instrument has a set of Channels (for example, normal/pizzicato/tremolo), every Channel also has a list of MIDI Actions.
Thus, we have two sets of MIDI Actions: the first one related to every Channel of Instrument, and the second one is channel-dependent.
To add MIDI Action to a certain position of the Score we use StaffText and SystemText elements, they just store names of selected MIDI Actions.

As I mentioned before, MIDI Action is a list of MIDI events, so it is possible to have duplicates of MIDI events in different places.

I wanted to implement it this way: store a list of used MIDI events in a Score. This list is accessible for every Instrument and Instrument's Channel. StaffText/SystemText will just store pointers/links/names of MIDI events. Notice that I'm going to store MIDI events in the Score, not sets of events (Actions). Since users will be able to add arbitrary MIDI events, there is no need to create sets of predefined events for them: they could construct any sequence of MIDI events by themselves.

The disadvantage derives from storing MIDI events in Score. Since Score will contain predefined and user-defined MIDI events, how can we share user-defined events across several scores?
Before this could be easily done by editing instruments.xml file - changes were affecting all new instruments in all scores.

Noseyparker - 23 July

Alot of time today was spent investigating the nogotofail server daemon and if it has functionality for inspecting unencrypted versions of HTTPS content. I'm now fairly certain the tool doesn't provide this.

I started investigations on how I could add this feature. I wrote a test connection handler to experiment with events the tool provides during the TLS handshake process, as well as HTTPS requests and responses. The event model is comprehensive and most events fired when I expected.

I also looked for examples of simple Python based man-in-the-middle TLS proxies to better understand what is required. Pymiproxy looks like a good candidate -

Some recent features I've added look like goof additions to the master nogotofail repository. I built a new Debian test server on Google Compute Engine and configured the software - it's working well. Tomorrow I'll add and test these features in a fork of the repository. Hopefully pull requests will follow soon ... to be continued!

MDN 7/22/2015

I am working on related_content button in MDN. This button allows users to retrieve drupal nodes related to the selected elements in the diagrams. I had a simpler functionality in the beginning of the project that allows users to click on a single diagram element to retrieve related nodes. I spent some time to figure out how to send an array of ids from client to server via ajax; most examples send only parameters. I have not finished today as I worked only a couple of hours; I should be done tomorrow.

22 July

Very productive day today. I finally found the bug and fixed it (along with the other 3 bugs I found after that) and finished up the OR code. Tomorrow, I'm going to polish the OR code and implement the compression threads.

Syndicate content