tiggerntatie
commented
9 years ago This has a good level of detail in its description of the inner-workings of your application. There are some things you should improve on, however.
First (and most important?) you have written your design spec in the "Issues" section of your repository, which is normally the place where people would go to post software bug notices and so forth. You should put your design spec in to the "Wiki" section of the repository, which is where your functional spec currently resides!
A design specification is often described as a document that a competent coder could use as a sort of set of instructions for creating the application from scratch. As such, it is a communication tool, and should be embellished with a few things:
- As you write, don't think, "this is what I did," but rather, "this is the way it ought to be." For example, phrases like, "I used the library objectAL", while true, put the reader in the wrong frame of mind for following the design.
- You have a lot of information packed into a few long paragraphs. They are sort of .. "run-on paragraphs". You could present this in a hierarchical format. At the top level are the source files or modules, which may correspond (or nearly so) with class definitions in your project. List these and any classes they contain. For each class, list the relevant attributes and methods that it defines.
- Alternatively, you could present this information as a series of bullet lists. First, the list of all UI elements, what they are for and how they behave. Next, a list of classes, then, for each class a list of methods that are pertinent to the design(in other words, what does an imaginary coder need to include in his code in order to ensure that they code a correctly working app?)
Next.. your code should be up to date in Github. This is not just for me to see that you've done it - rather, it is so that others can step in after you've lost interest in the project (!) and carry it forward. To make that easier you should:
- Update the code in Github. Ideally, you should do this every day, or even more often.
- How are you actually using ObjectAL in your project? Does your build tree include all of the files from the ObjectAL download, or just a subset. Are the ObjectAL files that you do use archived alongside your source code?
- If someone wanted to clone your github repository and open it in XCode, what would they have to do? Have you tested that process to ensure that it would actually work? Try it out: download or clone your Github files in a fresh directory and confirm that it can be done and used afterwards.
- Can your project be built and distributed as an app? Does XCode build an .app file as a matter of course? Have you tried sharing the app with a number of friends so you can at least be partially confident that it will run on more than one computer. What would someone have to do to build and distribute your app as an .app file?
As an overview of my app: there are several main view. The main view, written in swift, has a bunch of settings which the user can change. There are seven check boxes which are connected to AIOutlets, which when pressed, change the state to on, and when unclicked, to off. The tempo box and slider are connected such that when one is changed, the other changes with it, so that they are always in synchrony. The metronome sounds can be toggled between five different settings, which are all represented by their index. Or, one can unclick the "Döwnbeat" box such that there is not different noise on beat one for the metronome. All these values get placed in a dictionary "passeddict" that is passed to the JammingueController viewController via segway, to be used when actually playing sounds. In the bottom left, one can either design one's own chord progression, by inputting chord indexes into the box which opens up in a new window, run by chordSelectionViewController. However, the number of chords used must match the number of chords in the dropdown menu, or else the close button does not activate. After clicking the close button, a protocol passes the data from each box to the viewController, which is then passed using the segway to the JammingueController along with the other aforementioned data. PreSelectedViewController is mostly the same, except one simply needs to click on each button to pass the data of that button via protocol to the viewController, which then gets passed to the JammingueController to be used in the Jammingue mechanism.
In the JammingueController, chord progressions for all the instruments get initialized and set up, to be passed to the objective-c 'tryagain' fiile. After all this is done, using a header file NewJammingue-Bridging-Header.h, all the data can be transferred to the objective-c file, using tryagainInstance. From there, an NSTimer is set up using data initially from ViewController, sent to JammingueController, and then sent to tryagain, to run functions based on how fast the user input in the ViewController. Whenever the function is called by the NSTimer, and the beat of the measure is correct, the instrument will play its predesignated chord for that measure/beat. The beats in the measure are measured by timeTracker, which gets reset after the time signature is reached, and tuneCounter, which gets reset after the length of chord progression has been reached.
I used the library objectAL, because originally I wrote this app using AVAudioPlayer, but it didn't work because it was too laggy. It took a while to get all the frameworks working and such, mostly because I didn't know any objective-c (objectAL is written for objective-c and hasn't been updated in three years, so there is no swift version). All the sounds I used are midi-generated by garageband and exported.