Luma Touch Support Forums

Hi everyone,
Since we have undertaken to consider not only individual functions, but also invade the architecture of the application, I want to draw the attention of developers to two aspects of a special kind of architecture.

And I will explain the first one by the example of the manufacturer of audio equipment, the company RME. Imagine that LF is a functional part of an iPad as sound card RME BabyFace, designed for professional mobile-marching sound recording. The architecture of this sound card is made in such a way that in the copy purchased by the user (I note that the device itself can not be physically changed from the moment of manufacture), then a PRINCIPLE NEW FUNCTIONS are added with subsequent firmware changes, which were not present when the device was sold!
In most other hardware manufacturers, such improvements are possible only with the release of NEW hardware, but a firmware update only eliminate the detected bugs and improve compatibility with other equipment.
In this example, the developer has the ability to "deliver" to the consumer functions for which the buyer of other manufacturers need to buy another device.
This is to the aspect of frequent updates of iOS for a certain group of different models, and at the last conference Apple focused on the extension of iOS functions for tablets. Apple opens up more and more features for application interaction. The most striking example in this direction is AudioBus. Do not miss this aspect.
Why not add the ability to get an audio track through the IAA or as an AudioBus3 output point in the project from Cubasis, Auria, etc. directly?
I wish you one of the priorities to look "from the top of the mountain to the entire changing valley".

The second aspect concerns directly the request. The application already has a large set of various effects and transitions. But the aesthetics of a particular project often requires a one-time transition, which is not always needed and the repository simply clutters up. Androu already helped with such an example on the forum

Consider allowing users to create their own transitions and effects. This can be a separate additional application, placing the result in LF, or (as preferable) a separate sub-system within the application, using visual sources prepared in other applications (such as Affinity Photo).

And there is still a lack of an option to "unload" the interface by removing unused transitions and effects. After all, you can always reinstall the application to get them back with a rare need (or just enter the recovery point of the "factory state" in the settings).

Thank you for attention.

_________________
~ When they played I'd sing along, it made me smile ~
soundcloud.com/2l8m8

Good idea

_________________
Travel_Drone

In this case it will be much easier to write music synchronously with the video sequence, playing immediately on the instrument connected to the tablet in DAW, looking at the video monitoring window.

_________________
~ When they played I'd sing along, it made me smile ~
soundcloud.com/2l8m8

Great ideas, and I support them ... if they are possible

... but let's not run until we can walk without falling over occasionally

How about a built in 64 bit version of 'Snake'

_________________
.. Good things come to those who wait

Hi Lumaluke,

We have a OS-x product on the burner that will allow users to configure LumaFusion features, as well as load and unload content such as presets, transitions, titles etc. It will also auto convert iOS-unsupported media, and then re-conform with original full-resolution after editing on LumaFusion. That product will be called LumaConnect.

I like your thoughts about creating custom transitions and if we do that, then I think the feature would be integrated with LumaConnect or at the very least coincide with it's development.

Perhaps Chris will chime in here, but thanks for your thoughts!

_________________
Terri Morgan
LumaTouch

Thank you all very much for supporting the ideas. They appear in the process of working in the application.

Indeed, it is logical to "cook" more complex functions on the computer, in order to load the result into the iOS application. And this is good news!

Also I have a wish: watch for the optimal balance of functions, delegated to the desktop system from the mobile, so that the mobile was in the priority of the maximum possible functionality and did not turn over time into a cut-down satellite of the desktop app

Although must admit that right now, on iPad Pro 10.5, I encountered a serious slowdown when adding the selected part of a clip to the timeline, when working with the original clip a few gigabytes in size. But this is understandable. Just probed the limits of the permissible.
We just need to be patient and wait for the visual confirmation of the result without "twitching" and not interfering with the system to perform the operation.
And actually, when working with all the resource-intensive applications on iOS it became a habit before starting to work always hold down the Power button for 4 seconds and then 5 seconds to Home.

_________________
~ When they played I'd sing along, it made me smile ~
soundcloud.com/2l8m8

Hi LumaLuke,

Can you tell me about the original clip that slows things down? Maybe we could get a copy sent to us so we can test with it (unless it's a standard clip shot with the iPad or iPhone, then we can duplicate the problem)

_________________
Terri Morgan
LumaTouch

Hi Terry, thank you for help.

It was a test project and the "main culprit" of slowing the response has already been removed from it. I can describe the reason for this behavior, and if there is still a need for the project archive, I will find a way to recreate it and forward it to you.

Since when creating a project only Frame Aspect and Framerate are set, the work on the timeline goes with strongly differing in characteristics clips.
I know that it is always desirable to use clips with the same characteristics within the same project, but it does not always depend on me;).

In this project, clips with different characteristics are used. In this case, I no longer remember which clip was placed first on the timeline.
But I list the clips in the resulting sequence:

The 1st clip exported from the IntroMate application (1280x720 30fps PAR=1.0).

2nd clip - iPhone7p 4K 30fps.
Both of these clips formed the so-called Opening.

The 3rd clip is the first part of the plot (1280x720 29.97fps PAR=1.0);
Note that LF shows the correct frame rate, whereas the EXIF-Viewer rounds the value.

The 4th and 5th clips are from Assimilate Scratch, where they were processed as interlace source material from the Canon HF100 camera (AVCHD) and output was obtained as progressive 1440x1080 PAR=1.3333.
LF in this case shows the characteristics recalculated on Pixel Aspect Ratio = 1.0.

Just 5-th clip in size more than 3GB is the main culprit of essential slowdown. When placing its fragments on the timeline, the LF "freezes" for a couple of minutes. Then adequately reacted to navigation until the next piece placed on the TL.

Screenshots of clip characteristics are available in the archive:
For Terri

Naturally, after deleting clips with PAR = 1.3333 (Pixel Aspect Ratio) from the timeline, the project is "alive again"

_________________
~ When they played I'd sing along, it made me smile ~
soundcloud.com/2l8m8

Thanks for the detailed info. I suspect there is something in the encoding in that long clip that AVFoundation doesn't 'like'. Mixing aspect ratios and frame rates in itself shouldn't cause a problem (the same calculations of frame timing and screen fitting are called regardless of aspect ratio, resolution, fps, etc). If you can send us a copy of that clip, or an archive of the project, it might be helpful.

_________________
Chris P. Demiris
LumaTouch

@Chris
I sent you links in a PM.
Thanks!

_________________
~ When they played I'd sing along, it made me smile ~
soundcloud.com/2l8m8