Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Oct 2009
Offline Last Active Yesterday, 07:17 PM

Topics I've Started

Copy/paste fail

Yesterday, 06:03 PM

I am not sure if this is the right place, but...
This is a tale of copy and paste snafus.  (Not sure if this is the right term, but it sounds fancy...)
I was making CRC checking in my FLAC player, and I was copying a minor part of the CRC-8 part to make the CRC-16 part.  In the debugging I observed that all the generated values were in the range 0..255, but it was supposed to be 16 bit.
What I did was:
- (uint16_t)CRC16 {
    return mCRC16;
- (uint8_t)CRC16;
Notice the mismatching return values of the definition and implementation.
What I didn't notice was the compiler complaining with a WARNING (not an error) that:
So even though the method definition didn't match, the runtime was happy to use the "substitute" instead, providing me with wrong values.

Journals... purpose and guides?

Yesterday, 07:55 AM



I was just wondering if there exists any guides here to write journals?  I also wonder the purpose and if there is any rules or similar I need to know about, or if it is meant to be some sort of personal space where you write about things that other people might be interested in?


Just to be sure I don't mess up anything if I decide to write something.


I did try to search, but I couldn't find anything obvious here to answer my questions.

I am looking for a list view in Cocoa to handle a massive amount of data

30 July 2014 - 01:59 PM

In my application, I am using a NSTableView that is connected to a NSArrayController.  In my case, I am loading absolutely everything into memory, which in itself is not really a problem.  It is really fast and responsive, but I am planning to use a database instead to make the data more persistent.


I am almost certain I remember a kind of view in the past, that you just specified how many items were in the view, so the view knew the amount to scroll, then the view would ask for the data it needed for the items that were visible, and discard everything else, if it wanted.  In this way, I don't need to keep everything in memory at once.


My problem is that I don't remember what it is called, nor can I find it, and lastly, I don't know what to search for.


I would probably not have much problems making such a thing myself, but it will be a lot more work. If there is something already existing, I'd rather use that.  Does anybody have any ideas?

Trying to reduce the massive amount of variables in my struct

16 July 2014 - 09:42 AM

I am adding music formats to my audio player.  This time I am adding support for the ancient Amiga module format that was used in a lot of music trackers under lots of various names.  While I have not added every effect used by the "format" yet, it is playing my old music surprisingly well.


My question is about my structs.


I have organised the module (the song) in structs in a similar way to this:

typedef struct AmigaModule {
    uint8_t *ModuleName;
    uint8_t SampleCount;
    ModuleSample *SampleList;
    uint8_t SongPositions;
    uint8_t RestartPosition;
    uint8_t PatternTable[128];
    uint8_t MaxPattern;
    uint8_t ChannelCount;
    ModuleChannel *ChannelList;
} AmigaModule;

Where ModuleSample is a struct for each sample, and ModuleChannel is a struct for each channel in the song, with more structs to describe the pattern data for each channel, but this is not really interesting for my question.


ModuleChannel that has grown massively big with lots of arbitrary variables for each effect that tracks state of the song while it is playing, and I have made an effort in refactoring my code to a better structure.  Now I have removed all the state variables in its own struct to track states.


It looks something like this:

typedef enum ModuleChannelEffect {
} ModuleChannelEffect;

typedef enum ModuleChannelEffectSpecifier {
    //And more coming later...
} ModuleChannelEffectSpecifier;

typedef struct ModuleEffect {
    ModuleChannelEffect primaryEffect;
    ModuleChannelEffectSpecifier primaryEffectSpecifier;
    uint16_t parameter1;
    uint16_t parameter2;
    uint16_t parameter3;
} ModuleEffect;

And here is my issue:

See the three lines 'parameter1', 'parameter2', 'parameter3'?


In code, it looks like this:

currentChannel->effect.parameter1 = periodsTable[translatedPeriod];
currentChannel->effect.parameter2 = periodsTable[arpNoteIndex1];
currentChannel->effect.parameter3 = periodsTable[arpNoteIndex2];

And when I use those values:

currentChannel->period = currentChannel->effect.parameter1;

I like two things:


1. Code that is self-explanatory.

2. Generalisation, as long as it is not over-generalisation.


My problem is that 'parameter1' doesn't tell me anything, really.  In the portamento effect, is 'parameter1' the speed or the note I am sliding towards?  I could name the values for what they are, but then I wouldn't solve the problem with too many variables inside the struct again, because I would need to make lots of variables I don't always need to use.


Then it came to me that I could do something like this:

#define ArpeggioValue1 parameter1
#define ArpeggioValue2 parameter2
#define ArpeggioValue3 parameter3

Now I can reference the variable names in a more sensible and descriptive way:

currentChannel->effect.ArpeggioValue1 = periodsTable[translatedPeriod];
currentChannel->effect.ArpeggioValue2 = periodsTable[arpNoteIndex1];
currentChannel->effect.ArpeggioValue3 = periodsTable[arpNoteIndex2];
currentChannel->period = currentChannel->effect.ArpeggioValue1;

My question is whether this is an acceptable coding practise, is there a better way of doing this?  Do you have any other suggestion?  The point here is really that I want to learn to get better.  What I am doing now is working, but how would you go about it?  Make massive objects to handle this?  Some other thing?  What is the "best" way?



06 April 2014 - 07:18 PM

Coming from a big endian platform in the past, the good old Amiga computers that had the Motorola 680x0 processor series, I always found it weird with the seemingly backward little endian that is Intel 'x86.  I always thought that the choice of endianness was an arbitrary choice, a weird one, and according to wikipedia, it indeed is, but today I was thinking about some code that I was writing, and thinking "why is this really working"?
First, let me show you the code I am taling about:
NSInputStream *iStream = [[NSInputStream alloc] initWithFileAtPath:@"<somefile>"];
[iStream open];

uint64_t value = 0;

[iStream read:(uint8_t *)&value maxLength:1];
uint64_t myValue1 = value;

[iStream read:(uint8_t *)&value maxLength:2];
uint64_t myValue2 = value;

[iStream read:(uint8_t *)&value maxLength:4];
uint64_t myValue3 = value;

[iStream read:(uint8_t *)&value maxLength:8];
uint64_t myValue4 = value;
This works well on little endian platforms.
Hint: Look at where in the uint64_t I am reading the smaller values into and how I am storing the values afterwards.
If you were to do this on a big endian platform, you would need to write something like this (to my understanding):
[iStream read:(uint8_t *)(&value + 7) maxLength:1];
//store the value
[iStream read:(uint8_t *)(&value + 6) maxLength:2];
//store the value
[iStream read:(uint8_t *)(&value + 4) maxLength:4];
//store the value
[iStream read:(uint8_t *)&value maxLength:8];
//store the value
Unless there is some magic voodoo that I don't understand going on here, then I have found one good reason for the choice of little endian on an architecture, and to me it is not so arbitrary any more, even though it might really be...
Little endian, I do understand you existence a little bit more now... ;)
Oh yes, wikipedia also mentions this realisation:
"The little-endian system has the property that the same value can be read from memory at different lengths without using different addresses (even when alignment restrictions are imposed). For example, a 32-bit memory location with content 4A 00 00 00 can be read at the same address as either 8-bit (value = 4A), 16-bit (004A), 24-bit (00004A), or 32-bit (0000004A), all of which retain the same numeric value. Although this little-endian property is rarely used directly by high-level programmers, it is often employed by code optimizers as well as by assembly language programmers."