(removed)

sigma79

jason said:

@sigma79 said:
If you had made app in 2018. Or whenever ipads with the 12 or 13 chip were made.

Would the cpu be the same etc.

Is this the required chip for pianos in general because piano needs a low buffer setting ?

There are so many reasons for higher CPU. One is extremely high stereophonic polyphony with max. 88 keys due to possible sustaining, string resonance and body emulations and others. Shortest possible latency too, of course.

Thanks for answer.

Good info.

sigma79

@szczyp said:

@sigma79 said:
If you had made app in 2018. Or whenever ipads with the 12 or 13 chip were made.

Would the cpu usage be the same etc.

Is this the required chip for pianos in general because piano needs a low buffer setting ?

Question is not to me, but I have iPad Pro 4-th so chip is it M1, and I use 128 buffer (smallest in Drambo).

Sounds good though.

Are you playing keys via keyboard, yourself?

[Deleted User]

@sigma79 Casio AP21 (old model) 88 hammer action, playing myself and using iPad - but on phones (via interface).
Im „building” now sound absorbers to reducie echo in room, then after install I will listen more trough speakers in the casio (they are extremally good - one speaker design, so no crossband filtering, like „mixcube” speakers).

espiegel123

jason said:
HAL : The A12 is the absolute minimum, we would suggest. That‘s actually the same as Pianoteq suggests. Unfortunately the Apple AppStore does not provide any method for excluding insufficient devices for the release. And this in return will produce allot of returns and unsatisfied customers. ^^

This is a long term problem of the Apple AppStore, by the way.

Btw, I think this works quite well on my A10-equipped iPad 6. I hope that you won't exclude the app from running on this generation of devices.

jo92346

@espiegel123 I must be going something wrong because it barely runs on my 8th gen and as soon as I start playing something a little bit developed on my 9th gen I runs in cracks and weird sustain loops and sometimes crashes.

espiegel123

@jo92346 said:
@espiegel123 I must be going something wrong because it barely runs on my 8th gen and as soon as I start playing something a little bit developed on my 9th gen I runs in cracks and weird sustain loops and sometimes crashes.

What host are you using? What sample rate and what buffer size? How many instances are you trying to run at once. I am running one instance with a buffer of 256 or 512 and sample rate of 44.1k or 48k. I am using Loopy Pro but tried also in AUM with similar results.

Here is a rundown I did of a few iOS pianos (names blacked out for blind comparison). I am a mediocre piano player - so you may have to get past that:

Pianos in this comparison (not in order of appearance)
AudioLayer (salamander piano)
JAX Emporeor
JAX Superior
PurePiano
Ravenscroft

espiegel123

There is a short clip of each followed by a longer clip. All clips rendered from the same MIDI and then audio normalized to try to minimize loudness as a factor.

espiegel123

why?

espiegel123

jason said:

@espiegel123 said:
why?

That you are able to use it on an A-10.
I was so scared about the reported performance issues.

Anything pre-iPad 6 would probably not work. With a buffer of 256 o4 512, it was well-behaved for me. I don't run a lot of synths at the same time. I capture to audio as I go along rather than having multiple synths running in parallel.

espiegel123

Btw, if it would reduce cpu-use, a mono (i.e. non-stereo) mode would be a welcome option.

espiegel123

Why would you fear such comparisons? Different people find different sorts of comparisons helpful.

espiegel123

jason said:

@espiegel123 said:
Btw, if it would reduce cpu-use, a mono (i.e. non-stereo) mode would be a welcome option.

You mean, reducing the performance by omitting the second stereo channel? 🤔

Yes, if that would reduce cpu ise. In a lot of cases, particularly a mix with lots of instruments, a mono track is useful. There are a lot of cases when recording a band or ensemble where piano is recorded with a single mic.

espiegel123

jason said:

@espiegel123 said:
Why would you fear such comparisons? Different people find different sorts of comparisons helpful.

The users may select with sound preferences. That is OK. The point is, that JAX actually CAN sound like ANY of these samples. Because it has an inbuilt modelling engine. The others not. So one must demonstrate that one JAX has actually 4 base models and 16 fusion models, which all may sound different in certain aspects.

It would be helpful to provide presets that demonstrate that. Tweaking the parameters is an area where I find (and maybe this is the slow processor in my iPad) the JAX pianos a bit finicky. I was experiencing a lot of lag with the knobs and had difficulty making fine adjustments. So, I reset to the default and tapped the buttons in the matrix till I found one that I liked.

It would be handy having a set of presets that show off that it can sound like each of those pianos. I don't have the expertise with your pianos to know how to achieve each of those sounds.

espiegel123

jason said:
So I can only guess: we are not yellow, not green and not pink.

One of those is a JAX piano. Note that I used default settings for each piano. For the JAX piano I used the model that sound best to me. Others might prefer different ones. I felt like the default settings sounded better than the result when I tried to tweak the knobs as I don't have enough experience to do it well.

Gavinski

@espiegel123 said:

@jo92346 said:
@espiegel123 I must be going something wrong because it barely runs on my 8th gen and as soon as I start playing something a little bit developed on my 9th gen I runs in cracks and weird sustain loops and sometimes crashes.

What host are you using? What sample rate and what buffer size? How many instances are you trying to run at once. I am running one instance with a buffer of 256 or 512 and sample rate of 44.1k or 48k. I am using Loopy Pro but tried also in AUM with similar results.

Here is a rundown I did of a few iOS pianos (names blacked out for blind comparison). I am a mediocre piano player - so you may have to get past that:

Pianos in this comparison (not in order of appearance)
AudioLayer (salamander piano)
JAX Emporeor
JAX Superior
PurePiano
Ravenscroft

Hi Ed, could you please reveal the order of the pianos in the demo - that would be super helpful!

espiegel123

@Gavinski said:

@espiegel123 said:

@jo92346 said:
@espiegel123 I must be going something wrong because it barely runs on my 8th gen and as soon as I start playing something a little bit developed on my 9th gen I runs in cracks and weird sustain loops and sometimes crashes.

What host are you using? What sample rate and what buffer size? How many instances are you trying to run at once. I am running one instance with a buffer of 256 or 512 and sample rate of 44.1k or 48k. I am using Loopy Pro but tried also in AUM with similar results.

Here is a rundown I did of a few iOS pianos (names blacked out for blind comparison). I am a mediocre piano player - so you may have to get past that:

Pianos in this comparison (not in order of appearance)
AudioLayer (salamander piano)
JAX Emporeor
JAX Superior
PurePiano
Ravenscroft

Hi Ed, could you please reveal the order of the pianos in the demo - that would be super helpful!

I will after people have listened. Maybe I should post the video in its own thread. I think it is helpful for people to listen without knowing...reduces the powerful impact of preconceptions.

espiegel123

jason said:
Has anyone discovered still sample rate issues ??

There was at least one user reporting such per email that everything would be out of tune.

However, this actually should have been gone with version 1.9.

i just checked and the pitch is different in emporeor at 44.1 and 48 k. i tried in both aum and loopy pro

espiegel123

I was testing the sample without an interface connected. i can check tomorrow if the behavior is different on my device. The iPad 6 is a funny beast sample rate wise. It might be an outlier.

Gavinski

@espiegel123 said:

@Gavinski said:

@espiegel123 said:

@jo92346 said:
@espiegel123 I must be going something wrong because it barely runs on my 8th gen and as soon as I start playing something a little bit developed on my 9th gen I runs in cracks and weird sustain loops and sometimes crashes.

What host are you using? What sample rate and what buffer size? How many instances are you trying to run at once. I am running one instance with a buffer of 256 or 512 and sample rate of 44.1k or 48k. I am using Loopy Pro but tried also in AUM with similar results.

Here is a rundown I did of a few iOS pianos (names blacked out for blind comparison). I am a mediocre piano player - so you may have to get past that:

Pianos in this comparison (not in order of appearance)
AudioLayer (salamander piano)
JAX Emporeor
JAX Superior
PurePiano
Ravenscroft

Hi Ed, could you please reveal the order of the pianos in the demo - that would be super helpful!

I will after people have listened. Maybe I should post the video in its own thread. I think it is helpful for people to listen without knowing...reduces the powerful impact of preconceptions.

Good point

mistercharlie

This looks ready to buy in the App Store, for me. Is that correct?

Also, have you tried any of these out @LinearLineman? I’d love to hear your opinion.

Gavinski

@mistercharlie said:
This looks ready to buy in the App Store, for me. Is that correct?

Also, have you tried any of these out @LinearLineman? I’d love to hear your opinion.

He might be afraid to give it, after the blasting he got the last time he gave an opinion on a jax piano 😂. Just check the public betas out is probably the best way. Only positive comments allowed in this thread 🤪

mistercharlie

@Gavinski the betas are suspended at the moment. I will wait and see!

Gavinski

@mistercharlie said:
@Gavinski the betas are suspended at the moment. I will wait and see!

As mentioned above, I do really love the Emporeor. It's my new go-to piano

Gavinski

@espiegel123 said:

jason said:
Has anyone discovered still sample rate issues ??

There was at least one user reporting such per email that everything would be out of tune.

However, this actually should have been gone with version 1.9.

i just checked and the pitch is different in emporeor at 44.1 and 48 k. i tried in both aum and loopy pro

Yep, also found that in aum.

wim

Me too. The Emporeor sounds great. So great that I don't mind that I need to commit to audio early on due to my outdated hardware. Loopy Pro makes that super painless to do anyway.

I may not know a Bösendorfer from a Düsseldorfer, but I know what sounds great to me.

Gavinski

@wim said:
Me too. The Emporeor sounds great. So great that I don't mind that I need to commit to audio early on due to my outdated hardware. Loopy Pro makes that super painless to do anyway.

I may not know a Bösendorfer from a Düsseldorfer, but I know what sounds great to me.

Same. Brilliant sound

dspguy

jason said:
The sample rate issue problem.

The problem here is that it must work with all platforms.
It is obviously an initialization problem.

Hot switching sample rates on all Apple platforms is a potential PROBLEM.
We have started the app with 44.1, 96.0 and 48.0 kHz successfully on the mac so far. No detuning and correct sample rate selection inside the audio unit initialization.

However, the sample rate is always adjusted inside the initialisation process of loading the audio unit.
Then we changed it to be performed inside allocateResources(), which can be called by a host several times in correct sequence while runtime.

Obviously some hosts do handle this quite differently or not correctly at all.

The sample rate for audio units must be initialized in either one of these defined init function calls, otherwise it won”t work.

An audio unit is not supposed for doing any sample rate change detections at runtime for instance.
This still may work but it is not supposed to work this way.

Otherwise we do not understand Apples entire audio system frameworks at all. And Apple itself uses explicitly one of these initialisations in their host applications (at least on the mac platforms). Changing the sample rate in Logic Pro X at runtime is impossible. It always will stop the audio system and then re-initialize all audio units and the entire bus system, if a sample rate change occurs (i.e. if a new audio interface is connected).

This is a major conceptional problem of all Apple platforms, which is nowhere documented, causes loads of confusion and different problematic implementations.

Passing the sampling rate to your implementation in allocateRenderResources() should be fine, but maybe you could spin up a discussion in the App Development category.
I've yet to encounter a use case or a host application that messes this up (and I've used a lot between Reaper and GarageBand).

Host apps can and do have horrible quirks and bugs (even Logic Pro with respect to AUv3's), but this isn't one of them. Unless we suddenly see more apps breaking after an update.

dspguy

jason said:

@dspguy said:

jason said:
The sample rate issue problem.

The problem here is that it must work with all platforms.
It is obviously an initialization problem.

Hot switching sample rates on all Apple platforms is a potential PROBLEM.
We have started the app with 44.1, 96.0 and 48.0 kHz successfully on the mac so far. No detuning and correct sample rate selection inside the audio unit initialization.

However, the sample rate is always adjusted inside the initialisation process of loading the audio unit.
Then we changed it to be performed inside allocateResources(), which can be called by a host several times in correct sequence while runtime.

Obviously some hosts do handle this quite differently or not correctly at all.

The sample rate for audio units must be initialized in either one of these defined init function calls, otherwise it won”t work.

An audio unit is not supposed for doing any sample rate change detections at runtime for instance.
This still may work but it is not supposed to work this way.

Otherwise we do not understand Apples entire audio system frameworks at all. And Apple itself uses explicitly one of these initialisations in their host applications (at least on the mac platforms). Changing the sample rate in Logic Pro X at runtime is impossible. It always will stop the audio system and then re-initialize all audio units and the entire bus system, if a sample rate change occurs (i.e. if a new audio interface is connected).

This is a major conceptional problem of all Apple platforms, which is nowhere documented, causes loads of confusion and different problematic implementations.

Passing the sampling rate to your implementation in allocateRenderResources() should be fine, but maybe you could spin up a discussion in the App Development category.
I've yet to encounter a use case or a host application that messes this up (and I've used a lot between Reaper and GarageBand).

Host apps can and do have horrible quirks and bugs (even Logic Pro with respect to AUv3's), but this isn't one of them. Unless we suddenly see more apps breaking after an update.

In extended the “article” with some important additions at the bottom:

Furtermore, this is much more complicated. Theoretically and practically the entire Apple audio unit system is build in a way, that actually requires the host application to ask the plugin for the supposed sample-rate supported at initialisation. If the audio unit supports merely 44.1 kHz for instance and the host has 48000 Hz, then the host actually has to react with so-called sample-rate converters between. This is how Apples entire system is supposed to work and not differently! So allot of hosts actually are wrongly designed, by the way. Apples latest AVAudioEngine implementation (as a reference) exactly works this way and not anyhow differently.

PS: We are talking explicitly about AUv3 here.

The only host app that I have seen on iOS, that actually addresses this issue, is the Roland Zenbeats app, where you can ask the host to use the audio unit with its native exposed sample rate.

You need to see this from a user's perspective. They have many (sometimes even more than a hundred) Audio Units that have no problems with sampling rates, whether they use it from NanoStudio, BeatMaker3 or MultiTrackStudio. If your Audio Unit fails at this, there is a bug to be fixed, and a QA process to be updated on your side. Especially if your other Audio Units that are already in the app store also have such fundamental problems.

There are around 1000 Audio Units for iOS, all of which presumably got a good grip on this thing. In this situation, it offers users little value to use words that are only meaningful to developers, or to bash Apple / host app devs on this. Although they clearly deserve credit for some problems, but not this one.

BTW I totally don't get what you're saying about Zenbeats, but I'm not super familiar with it. Does it provide realtime resamplers for each audio unit instance that is somehow of acceptable quality and performance? I also wasn't aware of a plugin being able to communicate any preference or capability regarding sampling rate. Is this a recent update?

dspguy

jason said:
What is your point actually here?

I did not say that i will not change or look at the problems of my products. Surely I will.
But there are fundamental problems with the entire system and if all doing it wrong it is not automatically right.
So we actually have to discuss this!

But you are right. I will not continue the discussion here,
as I want to support my customers.

However, I do not need an (anonymous) teacher here too.

Who are you actually? My name is known.
So please say at least with whom I am talking here (or at least) who you think you are.

I offered my free advice by saying you need to look into allocateRenderResources(), and not worry about everything else you spent writing paragraphs on. This advice was given after having gone through a lot of learning, trial-and-error myself, and with the intent of helping you. Maybe you want to look at that reply of mine again.

But instead of taking that information and go on some bug hunting, you chose a different path, and I don't think it's a good look for a developer.

dspguy

jason said:

@dspguy said:

jason said:
What is your point actually here?

I did not say that i will not change or look at the problems of my products. Surely I will.
But there are fundamental problems with the entire system and if all doing it wrong it is not automatically right.
So we actually have to discuss this!

But you are right. I will not continue the discussion here,
as I want to support my customers.

However, I do not need an (anonymous) teacher here too.

Who are you actually? My name is known.
So please say at least with whom I am talking here (or at least) who you think you are.

I offered my free advice by saying you need to look into allocateRenderResources(), and not worry about everything else you spent writing paragraphs on. This advice was given after I went through a lot of learning, trial-and-error with the intent of helping you. Maybe you want to look at that reply of mine again.

But instead of taking that information and go on some bug hunting, you chose a different path, and I don't think it's a good look for a developer.

I do not care about of what you are thinking.
Because you sound like someone who want to teach me.
I cannot bear such things, sorry.

Because in ALL your posts here is a certain DISRESPECT audible.
All that from an anonymous!

However I usually can safely trust my instincts. ^^

An entitlement for teaching me (and the responding respect) requires at least
that I know, to whom I am actually talking or listening.

(This way I would be able to check whether these informations are of a value to me or not.)

.

Addendum: I did now read all his comments here and I do now understand.
Such kind of anonymous smart ass users (with such an enormous knowledge about just everything) did cross my ways all the life!

It sounds harsh and can be extremely unpleasant to see it spelled out that your product you've worked very hard on fails on an issue that is handled by everyone else.

But it's equally unpleasant for a user to discover issues of such magnitude just before a live performance (I was actually contacted in such a situation) or in midst of doing a real production project.

But despite such things being frustrating or unpleasant, sometimes you need a reality check to get you back on track, before you go spiraling down deeper into a communications rabbit hole (that could even end up impacting your product). It will benefit everyone, you included.

It's a bug, you fix it, no big deal. Contact host app developers if they need to fix bugs. I did so myself, and actually resolved a major missing feature in Reaper's AUv3 compliance, for example.
Feel free to put up a website listing host bugs, you don't need to take a blame when it's not deserved. It's a different story when the bug is in your implementation, though.