Re: Why is it wrong to have relationships without an inverse in Core Data?

[Luther Baker]

Ah. Which part is kludgy?

Parent *parent = ...;

Child *child = ...;
parent.activeChild = child;

Child *child2 = ...;
parent.activeChild = child2;

Child *child3 = ...;
parent.activeChild = child3;


Unless I'm missing something, there is no kludge or workaround with this
approach. The code just works. Its ultra clean and doesn't require whatever
it is you are doing to clean things up. Having to remember to implement
"prepareForDeletion" is a kludge. No?

Remember, the best code is no code at
all
.

Again, I'm late to this discussion and I'm surprised it wasn't brought up
... so maybe there is something else to consider - but on the face of it,
it seems simpler and easier to maintain.

-Luther


PS: As an aside, I'm also curious about a comment you made earlier.

>  I have no need for an inverse, why does Core Data?

It seems to me that whether or not you want to explicitly *use* an inverse
relationship is fundamentally different than *identifying* that it exists. Core
Data needs meta information and will likely be able to function better and
more efficiently if you can give it more meta information as opposed to
less - whether or not you actually use or leverage that relationship is
actually different than identifying it and telling Core Data.

For example, If a PROJECT can have only one active TASK at a time ... and a
TASK can only belong to one active PROJECT at a time, then the inverse
relationship exists - whether or not you want to identify or use it, it
still exists. Are you simply opposed to being forced to define that inverse
relationship?

Feels odd that, instead of accurately defining the inverse relationship ...
you instead, decide to implement callback methods to manually implement
cleanup code because, you somehow think that is cleaner than accurately
defining the inverse data relationship and letting Core Data just handled
it for you.

No worries, maybe there is some reason why you can't define the inverse
relationship that I missed or I'm being too pedantic. I feel like I'm
digging too much here! My apologies if that is the case. Sounds like you've
already decided your way forward - I was just curious.



On Wed, Jun 26, 2013 at 1:20 AM, Rick Mann  wrote:

>
> On Jun 25, 2013, at 22:57 , Luther Baker  wrote:
>
> > At the risk of sounding like an idiot for stating the obvious ... why not
> > create a (dummy) inverse relationship (Child.activeParent)? No one says
> you
> > have to use it ... or heck, maybe you want to use it.
> >
> > Parent.children<>> Child.parent
> > Parent.activeChild <-> Child.activeParent
> >
> > I just tested this and it works as expected. IE: setting
> Parent.activeChild
> > to different children between saves cleans up both ends of the
> relationship
> > automatically (each subsequent child's 'activeParent' field was
> > automatically cleared when I set a different child to the
> > Parent.activeChild property).
> >
> > I don't know, maybe I missed something.
>
>
> I think that works, and I've done it before, but I find it very kludgey. I
> think I prefer the one-way-with-prepareForDeletion approach instead.
>
> --
> Rick
>
>
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Still can't delete CoreData object

[Luther Baker]

Hi Rick,

Warning ... my suggestion does not actually solve your problem as stated
and I fear it runs the risk of starting a strange heretical war :( as I'm
not sure how folks in this group will receive the suggestion ... but if
this is indeed your own project, you may want to take a look at the MVP
pattern .

I'd suggest that a strong reference to a Core Data entity in your view code
is a code smell. It sounds like you're asking for trouble. Solutions
requiring connected entities in the view generally lead to some very dark
corners in the code. And yes, Apple's SDK seems to encourage and make it
very convenient but ideally, Core Data should be completely abstracted away
- down beneath the model layer.

I hope this is somewhat helpful. I don't mean to criticize. I never like to
post a question and get an answer back that basically says "You shouldn't
be doing that anyway" - so know that is not my intent here. Its the "give a
man fish ...vs... teach a man to fish" style of answer that I strove to
achieve with this response.

At any rate, remember, it's just a suggestion ... and as such, it, too,
comes with its own set of caveats.

-Luther





On Tue, Jun 25, 2013 at 5:36 PM, Rick Mann  wrote:

> A bit of additional info:
>
> The only job I can't delete is my "active" job. I keep a strong reference
> to that object in a view controller. I have that view controller set up to
> listen for changes to the MOC, and to forget that active object if it is
> deleted, but this seems to be what's causing the problem.
>
> If I first set that reference to nil, and THEN delete the object, I don't
> get the problem.
>
> But this clutters my delete code; I'd rather just watch for changes to the
> MOC. Is that unreasonable?
>
> On Jun 25, 2013, at 15:30 , Rick Mann  wrote:
>
> > I have a situation in which I can't delete one of my core data objects
> from a UITableView. The list is built using NSFetchedResultsController, and
> I delete the objects after the user swipes to delete with
> >
> >Job* obj = [self.resultsController objectAtIndexPath: inIndexPath];
> >[obj.managedObjectContext deleteObject: obj];
> >
> > I then save the MOC.
> >
> > My -controller:didChangeObject:atIndexPath:forChangeType:newIndexPath:
> delegate method gets called with NSFetchedResultsChangeDelete, and I call
> >
> >[self.tableView deleteRowsAtIndexPaths: @[ inIndexPath ]
> withRowAnimation: UITableViewRowAnimationAutomatic];
> >
> > But then, as part of the same MOC -save: call, it gets a
> NSFetchedResultsChangeInsert. Interestingly, the address of the object
> inserted is the same as the address of the object that was just deleted, as
> is its x-coredata URI, but all of its properties have default values.
> >
> > If I then try to delete the object again, it's data is , and the
> MOC -save method returns false, but no NSError is returned.
> >
> > Any ideas?
> >
> >
> > --
> > Rick
> >
> >
> >
> >
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> >
> https://lists.apple.com/mailman/options/cocoa-dev/rmann%40latencyzero.com
> >
> > This email sent to rm...@latencyzero.com
>
>
> --
> Rick
>
>
>
>
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com
>
> This email sent to lutherba...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Rick Mann]

On Jun 25, 2013, at 22:57 , Luther Baker  wrote:

> At the risk of sounding like an idiot for stating the obvious ... why not
> create a (dummy) inverse relationship (Child.activeParent)? No one says you
> have to use it ... or heck, maybe you want to use it.
> 
> Parent.children<>> Child.parent
> Parent.activeChild <-> Child.activeParent
> 
> I just tested this and it works as expected. IE: setting Parent.activeChild
> to different children between saves cleans up both ends of the relationship
> automatically (each subsequent child's 'activeParent' field was
> automatically cleared when I set a different child to the
> Parent.activeChild property).
> 
> I don't know, maybe I missed something.


I think that works, and I've done it before, but I find it very kludgey. I 
think I prefer the one-way-with-prepareForDeletion approach instead.

-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why is it wrong to have relationships without an inverse in Core Data?

[Luther Baker]

At the risk of sounding like an idiot for stating the obvious ... why not
create a (dummy) inverse relationship (Child.activeParent)? No one says you
have to use it ... or heck, maybe you want to use it.

Parent.children<>> Child.parent
Parent.activeChild <-> Child.activeParent

I just tested this and it works as expected. IE: setting Parent.activeChild
to different children between saves cleans up both ends of the relationship
automatically (each subsequent child's 'activeParent' field was
automatically cleared when I set a different child to the
Parent.activeChild property).

I don't know, maybe I missed something.

-Luther


On Mon, Jun 24, 2013 at 9:20 PM, Alex Zavatone  wrote:

>
> On Jun 24, 2013, at 8:52 PM, Graham Cox wrote:
>
> > Grocers (or should that be Grocer's?) are the only profession allowed to
> use an apostrophe to indicate that there's an 's' about to come up at the
> end of the word.
>
> That's not even a valid excuse.
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/lutherbaker%40gmail.com
>
> This email sent to lutherba...@gmail.com
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Affects of [interior]BackgroundStyle

[Ryan McGann]

Hi all,

I have a UI that is drawn on a a mainly white background. The text is comprised 
of a couple of different fonts other than Lucida Grande. The UI designer 
noticed that the fonts in the UI are rendering a bit thicker than what was 
mocked up in Photoshop.

I played around and was able to get the text inside some NSTableViews to look 
pretty close to the mockups using a kludge. Creating a custom NSTableRowView 
and overriding interiorBackgroundStyle to return NSBackgroundStyleDark (despite 
the fact that it's actually a white background) seems to help a great deal.

But it's a kludge, and only works for the table views & controls anyway. I'm 
more interested in knowing what the affects of [interior]BackgroundStyle are, and 
how it affects the text rendering. Specifically, the stroke on the text is a couple 
of pixels thinner when [interior]BackgroundStyle is set to NSBackgroundStyleDark.

Anybody know what exactly is being done by setting the background style, and 
how I can apply the same affect everywhere in my application?

Thanks,
Ryan

rmcg...@mac.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Michael Crawford]

On 6/25/13, Scott Ribe  wrote:
> This is what I've been thinking--with the importer asserted to a crazy
> extent, so that you get notified of anything that it doesn't completely
> understand.

Using assertions in an importer is one of my more-effective reverse
engineering techniques.

Take a guess at the document format.
Write an importer that reads that format.
Put assertions everywhere.
If your first guess is wrong, you'll trip an assertion.
Lather.
Rinse.
Repeat.

The other thing I do is run the importer under Valgrind.  That will
even flag out-of-bound reads by so much as one byte.  Valgrind
includes a machine code interpreter, that validates every memory
access, before passing system and library calls off to native code.

-- 
Michael David Crawford
mdcrawf...@gmail.com
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: AVAudioMix volume/gain curve seems nonlinear

[Jens Alfke]

On Jun 25, 2013, at 5:13 PM, Gordon Apple  wrote:

> I don’t have the definitive answer to your question of how the AV volume 
> level is actually defined, but it would make sense for it to be linear in dB 
> (i.e, logarithmic in power).  dB is always a power measurement.  

Right. The cubic curve that the AU mixer uses is, I think, a cheaper 
approximation of this.

> AVAudioMix does the same to get the composite level.  If not, they need to 
> rethink this.

No, it’s pretty clearly just a linear interpolation of the raw sample values. 
Not very useful on its own IMHO.

> If the volume curve turns out to not be what you want, there is nothing 
> preventing you from imposing your own function mapping from your controls 
> (fades, whatever) to AV’s volume level.  You can customize it any way you 
> want.

Yeah, I wrote a function to do this. It breaks the time range of the fade into 
a number of equal segments, applies the cubic mapping to the volume at each 
point, and adds a linear fade between each. I arbitrarily decided to space the 
segments at least 1/4 second apart but use no more than 10.

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: AVAudioMix volume/gain curve seems nonlinear

[Gordon Apple]

I don¹t have the definitive answer to your question of how the AV volume
level is actually defined, but it would make sense for it to be linear in dB
(i.e, logarithmic in power).  dB is always a power measurement.  Growing up,
I was always told that a dB was the smallest volume change a person could
detect.  While that is not the definition, it is close to being true.  A Bel
is the base 10 logarithm of a power ratio, often referenced to a standard
level (e.g., dBm.), and a dB being 10x that.  Using a volume control and a
meter in some of my AVFoundation implementations, the volume and meter seem
to be linearly related.  When I meter combined audios, I convert each back
to power, add, then reconvert to dB.  I hope AVAudioMix does the same to get
the composite level.  If not, they need to rethink this.

If the volume curve turns out to not be what you want, there is nothing
preventing you from imposing your own function mapping from your controls
(fades, whatever) to AV¹s volume level.  You can customize it any way you
want.


On 6/25/13 2:00 PM, " Jens Alfke  wrote:

> [I¹m starting to work with AVFoundation and have some issues. I¹ve tried
> posting on the coreaudio-api list but haven¹t gotten any responses, so I¹m
> wondering whether cocoa-dev is a better place for discussing this API (since
> it¹s Objective-C-based.) Here¹s my most recent question:] The volume level
> mapping (gain curve) used by AVAudioMix seems to be very different from the
> one used by the AudioUnit kStereoMixerParam_Volume property. After porting my
> audio-editor app to AVFoundation ‹ which took only two days! ‹ I¹m noticing
> that fade-ins and fade-outs sound very different than they used to.
> Subjectively, most of the audible change in the gain curve is at the low
> levels, like from 0.0 to 0.25, with much more gradual change from 0.25 to 1.0.
> Compared to the AudioUnits curve, it seems a lot less audibly linear. I know
> that the human ear¹s response to volume levels is very nonlinear, so
> AVAudioMix might actually be using linear interpolation, while AudioUnits
> might be using something like a cubic curve. Is there any way to customize
> this curve? The new one seems less useful overall (it doesn¹t sound linear),
> and the large difference from the old curve makes a lot of careful crossfades
> that I¹ve created in my app sound completely wrong now. (The workaround, I
> suppose, is to use a series of segments instead of one interpolation, with a
> lot of calls to -setVolumeRamp:Š I hope there aren¹t scalability problems with
> having lots of control points in the volume level of a track.) ‹Jens


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Still can't delete CoreData object

[Rick Mann]

A bit of additional info:

The only job I can't delete is my "active" job. I keep a strong reference to 
that object in a view controller. I have that view controller set up to listen 
for changes to the MOC, and to forget that active object if it is deleted, but 
this seems to be what's causing the problem.

If I first set that reference to nil, and THEN delete the object, I don't get 
the problem.

But this clutters my delete code; I'd rather just watch for changes to the MOC. 
Is that unreasonable?

On Jun 25, 2013, at 15:30 , Rick Mann  wrote:

> I have a situation in which I can't delete one of my core data objects from a 
> UITableView. The list is built using NSFetchedResultsController, and I delete 
> the objects after the user swipes to delete with 
> 
>Job* obj = [self.resultsController objectAtIndexPath: inIndexPath];
>[obj.managedObjectContext deleteObject: obj];
> 
> I then save the MOC.
> 
> My -controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: 
> delegate method gets called with NSFetchedResultsChangeDelete, and I call
> 
>[self.tableView deleteRowsAtIndexPaths: @[ inIndexPath ] withRowAnimation: 
> UITableViewRowAnimationAutomatic];
> 
> But then, as part of the same MOC -save: call, it gets a 
> NSFetchedResultsChangeInsert. Interestingly, the address of the object 
> inserted is the same as the address of the object that was just deleted, as 
> is its x-coredata URI, but all of its properties have default values.
> 
> If I then try to delete the object again, it's data is , and the MOC 
> -save method returns false, but no NSError is returned.
> 
> Any ideas? 
> 
> 
> -- 
> Rick
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/rmann%40latencyzero.com
> 
> This email sent to rm...@latencyzero.com


-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Still can't delete CoreData object

[Rick Mann]

I have a situation in which I can't delete one of my core data objects from a 
UITableView. The list is built using NSFetchedResultsController, and I delete 
the objects after the user swipes to delete with 

Job* obj = [self.resultsController objectAtIndexPath: inIndexPath];
[obj.managedObjectContext deleteObject: obj];

I then save the MOC.

My -controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: delegate 
method gets called with NSFetchedResultsChangeDelete, and I call

[self.tableView deleteRowsAtIndexPaths: @[ inIndexPath ] withRowAnimation: 
UITableViewRowAnimationAutomatic];

But then, as part of the same MOC -save: call, it gets a 
NSFetchedResultsChangeInsert. Interestingly, the address of the object inserted 
is the same as the address of the object that was just deleted, as is its 
x-coredata URI, but all of its properties have default values.

If I then try to delete the object again, it's data is , and the MOC 
-save method returns false, but no NSError is returned.

Any ideas? 


-- 
Rick




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Jens Alfke]

On Jun 25, 2013, at 10:47 AM, Wim Lewis  wrote:

> FWIW, Omni's open-source data objects framework was our response to our 
> difficulties with CD. It doesn't do everything CoreData does, and it does 
> some things CoreData doesn't, but if you're considering taking this route, 
> you might be interested in looking at it.

Likewise, Couchbase Lite[1] and its predecessor TouchDB[2] are other 
alternative persistent storage libraries (which I happen to work on!) Their 
priorities are different than CoreData — sync is #1, with with object-mapping 
being less advanced. 

If your app needs to be able to sync data with a server or with other clients, 
I think it’s a no-brainer to choose over CoreData, given the limitations and 
poor quality of the latter’s iCloud integration. But they’re good as general 
purpose data stores as well, since they’re open-source, open-format, 
cross-platform, and give you API access to the underlying document-based NoSQL 
database.

—Jens

[1] https://github.com/couchbase/couchbase-lite-ios
[2] http://touchdb.org
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Wim Lewis]

On 25 Jun 2013, at 7:44 AM, Steve Sisak wrote:
> The safest thing to would probably to be to implement a Core Data "workalike" 
> with a documented database schema and possibly an importer for "real" code 
> data files.


FWIW, Omni's open-source data objects framework was our response to our 
difficulties with CD. It doesn't do everything CoreData does, and it does some 
things CoreData doesn't, but if you're considering taking this route, you might 
be interested in looking at it.
   https://github.com/omnigroup/OmniGroup/tree/master/Frameworks/OmniDataObjects



___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Noah Desch]

Using coredata with a documented format should probably be accomplished with an 
NSIncrementalStore subclass rather than trying to reverse engineer the existing 
undocumented format. 

Noah Desch

On Jun 25, 2013, at 11:30 AM, Scott Ribe  wrote:

> On Jun 25, 2013, at 8:44 AM, Steve Sisak wrote:
> 
>> The safest thing to would probably to be to implement a Core Data 
>> "workalike" with a documented database schema and possibly an importer for 
>> "real" code data files.
> 
> This is what I've been thinking--with the importer asserted to a crazy 
> extent, so that you get notified of anything that it doesn't completely 
> understand.
> 
> -- 
> Scott Ribe
> scott_r...@elevated-dev.com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
> 
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/deschnl%40me.com
> 
> This email sent to desc...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Charles Srstka]

On Jun 25, 2013, at 9:44 AM, Steve Sisak  wrote:

> At 8:52 PM -0500 6/22/13, Charles Srstka wrote:
>> 2. Since the format isn't published, there's no reason that Apple 
>> might make changes to it in the future,
> 
> I think you'll find that the reason Apple doesn't publish some 
> specifications is specifically so they CAN change them w/o breaking 
> 3rd party applications.

Yeah, I meant to say that there wasn't any reason that Apple might *not* make 
changes to it in the future, which to me is a problem. If Apple were to change 
the Core Data format, then "FooWriter 1.0" running on 10.10", "FooWriter 1.0 
running on 10.9", "FooWriter 2.0 running on 10.10", and "FooWriter 2.0 running 
on 10.9" would be completely different document formats. A user could find 
himself incapable of opening a FooWriter 2.0 document even though he has 
FooWriter 2.0, because he's using a different version of the OS. Another user 
might try to send a file to another user for collaboration and find that he 
can't export it in a way that the other user will be able to open, since the 
other user is running an earlier version of OS X. Can you imagine the kind of 
confusion this would cause to the userbase? I guarantee you'd be hearing about 
it extremely frequently from your customers.

Charles

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

AVAudioMix volume/gain curve seems nonlinear

[Jens Alfke]

[I’m starting to work with AVFoundation and have some issues. I’ve tried 
posting on the coreaudio-api list but haven’t gotten any responses, so I’m 
wondering whether cocoa-dev is a better place for discussing this API (since 
it’s Objective-C-based.) Here’s my most recent question:]

The volume level mapping (gain curve) used by AVAudioMix seems to be very 
different from the one used by the AudioUnit kStereoMixerParam_Volume property. 
After porting my audio-editor app to AVFoundation — which took only two days! — 
I’m noticing that fade-ins and fade-outs sound very different than they used 
to. 

Subjectively, most of the audible change in the gain curve is at the low 
levels, like from 0.0 to 0.25, with much more gradual change from 0.25 to 1.0. 
Compared to the AudioUnits curve, it seems a lot less audibly linear. I know 
that the human ear’s response to volume levels is very nonlinear, so  
AVAudioMix might actually be using linear interpolation, while AudioUnits might 
be using something like a cubic curve.

Is there any way to customize this curve? The new one seems less useful overall 
(it doesn’t sound linear), and the large difference from the old curve makes a 
lot of careful crossfades that I’ve created in my app sound completely wrong 
now.

(The workaround, I suppose, is to use a series of segments instead of one 
interpolation, with a lot of calls to -setVolumeRamp:… I hope there aren’t 
scalability problems with having lots of control points in the volume level of 
a track.)

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Scott Ribe]

On Jun 25, 2013, at 8:44 AM, Steve Sisak wrote:

> The safest thing to would probably to be to implement a Core Data "workalike" 
> with a documented database schema and possibly an importer for "real" code 
> data files.

This is what I've been thinking--with the importer asserted to a crazy extent, 
so that you get notified of anything that it doesn't completely understand.

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice





___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Core Data Reverse Engineering KickStarter Project

[Steve Sisak]

At 8:52 PM -0500 6/22/13, Charles Srstka wrote:
2. Since the format isn't published, there's no reason that Apple 
might make changes to it in the future,


I think you'll find that the reason Apple doesn't publish some 
specifications is specifically so they CAN change them w/o breaking 
3rd party applications.


A counter-example would be QuickTime which is (was) a bit too well 
documented to make the transition to 64-bit.


-

The safest thing to would probably to be to implement a Core Data 
"workalike" with a documented database schema and possibly an 
importer for "real" code data files.


HTH,

-Steve
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com