Ableton in the Qt community

In addition to talking about the Push with Ableton, we had a chance to talk about joining the Qt Project as a contributor.

Ableton started contributing to Qt last year, what was the thing that got you started?

Working closely with the Qt Project is part of the Ableton Open Source strategy. It is just a natural step! Our products are invested in the Qt technology and it is unlikely that we will switch GUI frameworks in the coming years. Sometimes we hit the limits of Qt and we file specific bugs whenever we can, so becoming more involved with larger initiatives will help us ensure that Qt addresses our needs in the future.

We have already been working on contributing patches we made to Qt during our development process, some of which will be released as part of Qt 5.6 and 5.7, depending on when they reached the Qt repositories. The contributions to date have been related to QML plugins and use of QAbstractItemModel from QML. We expect to be able to make more significant contributions soon.

What would be an easy way to start contributing to Qt?

Filing bug reports is an easy way to contribute to Qt. Responses to bugs don’t always result in fixes in Qt, but sometimes result in good ways to redesign, using QML in a more-idiomatic way to avoid the bug. Adding minimal representative test cases with bug reports helps with getting quality responses from Qt developers.

Code contributions to Qt are a little bit more complicated, but the process of using gerrit is well-documented. We already use Git at Ableton, so from a tooling point of view, we didn’t have much more to learn after signing the Contribution Agreement.

Attending the Qt World Summit and previously the Qt Developer Days was a useful way to get in contact with Qt engineers to review some of those contributions.

Any tips for other companies that are thinking of having a stronger presence in the Qt community?

Start, then iterate. Filing quality bug reports is an easy and cheap way to begin exploring the community and to start to identify the people working on various areas of Qt. Reading the development mailing list and some commits in the Git repos also creates a broader picture of how Qt is made.

From there it’s just a case of turning from an accessor into a mutator. Getting to grips with Git and the contribution process is a hurdle, but it comes with the reward of not having to carry fixes or feature extensions in external patches.

Beyond that, a company needs to examine the benefits, come up with a strategy and think about how that presence fits into the structure of the organization.

What do you see as the benefits to Ableton in being present in the Qt community?

A recent blog post by Andy Wingo relates this to Conway’s Law, namely “To minimize your costs, you must somehow join the community of people that make your dependency”.

Contributing helps us to make more coherent software by ensuring that Qt has the interfaces we require and also by ensuring that we use the interfaces correctly and stay up to date with development and new releases. It is important to us that Qt is not a read-only black box.

Have you been active on the forums and mailing lists? Do you use them as information sources?

The forums and mailing lists are often good places to find information and best practices relating to Qt, but our engineers are not currently active in them. Often we find it is easier to walk to a knowledgeable colleague to ask a question instead of posting to the forums.

We expect to become more active on the development mailing list to discuss design issues relating to features we contribute.

How do you see the community being able to work together with you?

We are hoping for feedback on the design and implementation of code we submit to Qt in order to learn more from the experts. Unfortunately, a lot of the code which goes into Ableton products is not Open Source so we can’t get direct feedback on all of it, but it would also be great to get some feedback on the libraries we have already published for the community on Github.

One of those libraries, Aqt-Stylesheets was presented at Qt Developer Days 2014 and awarded the ‘Most valuable lightning talk‘.

The Aqt-Cassowary library is generally useful for particularly dynamic layouts and we think it fits well into the QML design model.

How do you balance work on the product and work on Qt?

We’re still trying to figure that out.

Our priority is to create the best quality products we can. There are already some cross-sectional teams in Ableton which work on internal libraries, and an extension of that structure might work for our Qt contributions. To date our contributions have been individual stories in our planning as needs arise. Adding the right balance of structure to that is something we would like to hear other opinions about in the comments!

Again, thank you very much for the discussion, it has been a pleasure to learn how Ableton is present in the Qt community and about the Ableton products.

Thanks again for taking the time to feature us on the Qt blog. We look forward to review feedback from the Qt contributor community, engaging in design discussions about use of Qt/QML in products like Push and our open-source offerings!

The post Ableton in the Qt community appeared first on Qt Blog.



Source :- Qt Blog http://ift.tt/1Yr3dcA

Introducing Long Term Support

With Qt 5.6 we are introducing the first Long Term Supported (LTS) release of the Qt 5 series. There will be several Qt 5.6.x patch level releases created during the next three years – also after the next Qt 5.x releases become available. Commercial licensees eligible for technical support will also be able to submit support requests longer for the LTS release.

Current LTS release has been Qt 4.8, and with its support ending at the end of 2015, it is time to introduce the next LTS release. Qt 5.0.0 was released three years ago and we have done a huge amount of improvements since then, as well as provided many good and widely used releases. Thanks to recent improvements in our releasing infrastructure we now have a sustainable way of developing parallel Qt releases with different sets of supported platforms and compilers.

As our LTS promise, we guarantee that Qt 5.6 will be supported for three years via standard support, after which additional extended support can be purchased. During this time period, even though following Qt releases (5.7 onwards) are already out, Qt 5.6 will receive patch releases providing bug fixes and security updates. Typically we have provided just one or two patch level releases for each Qt 5.x release, and this is planned to continue also in the future for the non-LTS releases. For Qt 5.6 LTS release the amount of patch releases will be higher, as we aim to provide these throughout the three year period.

With Qt 5.6 we will also roll out a change to the commercial support terms and conditions to recognize LTS versions of Qt, with the three year standard support period. At the same time we are reducing the standard support on non-LTS releases of Qt to be one year. There will be an option to purchase extended support for both LTS and non-LTS releases. The changed support terms do not affect already released Qt 5.x releases, these are supported two years from the release of next Qt version, as defined in the current support terms.

In addition to security fixes, error corrections and improvements provided by the LTS patch releases, we may also add support for new operating system and compiler versions to an LTS release of Qt, when possible. It should be noted that the deprecated modules and technology preview modules are not subject to the LTS.

We had a strong focus on improving quality and providing feature parity with Qt 5.5, for example in multimedia and connectivity areas, and have continued to improve further in Qt 5.6. Our aim is to provide a solid baseline with support for C++98 and C++11 compilers, just like before. The next release, Qt 5.7, will drop support for older compilers allowing us to leverage C++11 functionality in the Qt modules themselves. So for those wishing to use compilers such as VS2008, VS2010, and gcc 4.6, Qt 5.6 continues to be an excellent choice in the years to come.

The Qt 5.6 Beta release is now available, check it out if you have not yet done so. We are working hard to further fix and polish it with the target of having the Qt 5.6.0 final out in Q1/2016.

The post Introducing Long Term Support appeared first on Qt Blog.



Source :- Qt Blog http://ift.tt/1T5A5RA

Qt 5.6 Beta Released

It is my pleasure to announce that we have released Qt 5.6 Beta today, with binary installers available for convenient installation. Qt 5.6 will be a long-term supported release as we announced at the Qt World Summit in the beginning of October. This means Qt 5.6 support for 3 years along with additional patch-level releases. Let’s take a look at some of the highlights of the forthcoming release!

Long-Term Support

Qt 5.0.0 was released 3 years ago and we have done a huge amount of improvements since then. Therefore, we believe that it is time to create a Long-Term Supported (LTS) release with Qt 5.6. Our previous LTS release was Qt 4.8, which is running out of support in December. Most of you have already upgraded to Qt 5, but if you still have active projects in Qt 4 we encourage to migrate now.

Qt 5.6 will be supported for 3 years, after which additional extended support can be purchased. During this time period, even though following Qt releases (5.7 onwards) are already out, Qt 5.6 will receive parallel patch releases bringing bug fixes and security updates. We will also aim to provide support for new operating system and compiler versions when possible, however this can not be fully guaranteed even for an LTS release. Furthermore, it should be noted that the deprecated modules and technology preview modules are not subject to the LTS.

If you wish to know more about LTS, please check a blog post describing how it works.

New CI system – More Power to Qt Releasing

To build a foundation for the LTS Qt 5 release, we have been developing our continuous integration and releasing infrastructure. After all, as Qt is released and thoroughly tested on a multitude of different platforms and configurations, there is quite an infrastructure behind making all this possible. A new CI system, called Coin for COntinuos INtegration, has been developed and taken into use with Qt 5.6.

With the new CI system we are also using the binaries produced during the CI run in the Qt release packages. This prevents us from having to make new builds for packaging, saving time on integrating changes and creating new packages. In addition to time, the new approach saves a significant amount of CPU cycles in our cluster. Qt 5.6 Beta is the first release with CI produced binaries, so we ask that you please report all issues you encounter. This will help us fine-tune the system for RC and final.

High-DPI Support

One of the biggest new features coming with Qt 5.6 is a fully rewritten cross-platform High-DPI support. It allows applications written for standard resolution displays to be automatically scaled when shown on high-pixel-density displays. Using the new High-DPI support, Qt automatically adjusts font sizes, window elements, icons and graphics in general in a Qt application based on the pixel density. High-DPI support allows applications to adjust automatically even when the user moves a window from one display to another with a different pixel density.

Windows 10 Fully Supported + VS2015 binaries!

We have supported Windows 10 to a large extent already with Qt 5.5 and will now provide full support to both the win32 and WinRT APIs of Windows 10. Qt applications run on Windows 10 desktop PC’s, tablets and phones – and can be distributed via the Windows Store. For native Windows win32 applications moving to Windows 10 and the new WinRT API means a major rewrite, but with Qt is is a matter of simply compiling your application for WinRT.

In addition to Windows 10 support, Qt 5.6 also provided pre-built binaries for the Visual Studio 2015 compiler. Unfortunately, VS Add-In no longer works with VS2015, but we’ll update the VS Add-In for users of earlier Visual Studio versions with the release of Qt 5.6.0.

Other New Features

In addition to things mentioned here, Qt 5.6 adds many other new features and improvements. Please check the wiki for the most important new things in Qt 5.6.

Webkit and Qt Quick 1 Removed

We have removed WebKit and Qt Quick 1 from Qt 5.6 release content. The source code is still available in the repositories, but these are not packaged with Qt 5.6 any more. Qt Script remains deprecated, but is included in Qt 5.6 release.

Qt 5.6 Timeline

With the Beta release now out, we hope to get a lot of feedback from you and will polish Qt 5.6 further towards the Release Candidate and 5.6.0 final in the coming months. We are targeting to release the Qt 5.6.0 LTS final in Q1/2016.

Get Qt 5.6 Beta

Qt 5.6 Beta is now available for download in the Qt Account web portal (register here) or from download.qt.io.

Known issues of Qt 5.6 Beta are listed in the wiki. As always, please provide feedback via the Qt Project mailing lists, IRC, and when appropriate, create bug report at bugreports.qt.io.

 

 

 

The post Qt 5.6 Beta Released appeared first on Qt Blog.



Source :- Qt Blog http://ift.tt/1PcGH1f

Qt Champions for 2015

As the year is coming to an end soon, it is time to announce the 2015 Qt Champions!

Qt_Champion_200

Qt Champions are the people who go the extra mile for Qt. They do amazing things and surprise you with their dedication to Qt.

As last year, we have four Qt Champions for 2015. The number is not fixed, but these four nominees have made a big difference in the Qt community in 2015.

Without further ado, the Qt Champions for 2015 are:

  • Jürgen Bocklage-Ryannel and Johan Thelin for their work on the Qt5 Cadaques book. The Qt5 book covers all the aspects of development with Qt5 with an emphasis on QML. The book is freely available under a Creative Commons license for anyone contribute to and download and it has been translated to several different languages. Jürgen and Johan together with other community members helping out have created an excellent resource for developers who are starting their journey to Qt.
  • Iori Ayane for his many books on Qt and active participation in multiple areas of the Qt community. Iori-san has written multiple books on Qt in Japanese. He is also very active in the Japanese Qt scene, and during the last year he has also started contributing patches to Qt! All this makes for an impressive contribution to the Qt community.
  • And last, but not least, Samuel Gaist, who has continued his incredible activity on the Qt forums. He has also stepped up his activity on the bugtracker and code contribution side of the Qt project. Altogether his continued participation level is so impressive, that he is being nominated a lifetime title of Qt Champion.

Every new Qt Champion will receive a one year full Qt commercial license in addition to special Qt Champion items and invites to major Qt events during 2016.

Congratulations to all the new (and old) Qt Champions!
We’ll be telling you more about the Qt Champions and what they have done in the Qt community in January.

The post Qt Champions for 2015 appeared first on Qt Blog.



Source :- Qt Blog http://ift.tt/1QrdhOo

Qt Creator 3.6.0 released

We are happy to announce the release of Qt Creator 3.6.0.

This release includes a big contribution: An editor for UML-style diagrams. It is in experimental state and needs to be turned on through Help > About Plugins > ModelEditor. Since it features too many diagram types and element styles to even scratch on in this blog post, I’ll not even try and just refer you to the documentation. Many thanks to Jochen Becher!

Clang Fix-it integrationThe Clang based C/C++ code model received many improvements. The Clang Fix-its are now integrated into Qt Creator’s refactoring actions. We turned on more warnings, and show the warning or error and the context in which it occurs in different styles. You can configure which warnings are shown in the C++ > Code Model options.

Qt Quick Designer now has an action for switching between a .ui.qml file and the usage in the corresponding .qml file, similar to the Switch Source/Form action in Qt Designer for widgets. We also made the previously commercial-only connection editor and path editor available to all users.

QMake projects got a build configuration type for profiling (release with separate debug symbols). CMake projects got build configuration types for Debug, Release, ReleaseWithDebugInfo and MinSizeRelease. On OS X you can now choose if Qt Creator should consider the file system as case-sensitive or case-insensitive (Preferences > Environment > System). There have been many more improvements and fixes. Please refer to our change log for a more detailed overview.

You find the opensource version on the Qt download page, and commercially licensed packages on the Qt Account Portal. If you are evaluating Qt you can go straight to http://ift.tt/XbP7NM. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on irc.freenode.net, and on the Qt Creator mailing list.

Note: Starting with Qt Creator 3.6 we no longer provide prebuilt binaries for Linux 32-bit. Building Qt Creator on that platform is still supported though.

The post Qt Creator 3.6.0 released appeared first on Qt Blog.



Source :- Qt Blog http://ift.tt/1YheGGh

Ableton Push – Qt in music making

Berlin-based music company Ableton recently released the new Push, a digital instrument to create and perform music. It is a really impressive tool, take a look:

As the Push UI is built with Qt, we had a chance to ask Stephen Kelly, Benjamin Jefferys and Nikolai Wuttke – developers at Ableton – about how it was built and how it works.

Ableton has been around for a long time, where did it all start?

It all started in an apartment in Berlin back in 1999. The three founders – Gerhard Behles, Bernd Roggendorf and Robert Henke – wanted to create an alternative to the linear workflow of established DAWs (Digital Audio Workstations). In 2001 Ableton released Live 1 and moved into the workspace that we still occupy today – just a few streets from the apartment where the first lines of code were written. We have since released nine major versions of Live, and in 2013 we announced our first hardware instrument: Push, which was designed by Ableton but manufactured by Akai. This was well received by the community, but we wanted to evolve the concept so we completely redesigned Push and took hardware engineering in-house. We released the new Push at the beginning of November, together with Live 9.5 and Link.

You mentioned Live and Push, can you give a short overview of the different products you have, and how Qt fits in there?

We make three products: Live, Push and Link. Live is software for creating musical ideas, turning them into finished songs, and also taking them onto the stage. Push is a hardware instrument that puts everything you need to make music with Live at your fingertips. We’ve also recently developed Link – a technology that keeps devices in time over a wireless network. It is embedded within Live but it is also inside an increasing number of iOS music-making apps. The new Push is our first released product using Qt technology – for its animated display.

Can you give a general overview of the architecture used in Live/Push?

The updated Push hardware is designed to enable new workflows for music makers. Part of the intention of the hardware product is to allow a music maker to stay in the creative flow, without needing to turn to a different interface on a computer. The hardware needs to be able to show the user everything they need to see, in order to make music, from detailed waveforms to browsing for samples.

The interaction between the Push hardware and Live is a little complicated, so let’s start with a diagram:

Push Architecture DiagramPush communicates with the computer via two protocols over a USB interface, one of which is standard MIDI. This is a bidirectional protocol. Live uses it to control the pad colors and button lights on the hardware. When the user presses a button or a pad, a signal is sent over the MIDI channel back to Live. The other protocol communicating over USB allows sending image data to the hardware display. This means Push doesn’t need a processor running a more complex operating system and application to show GUI elements on the screen. The processor on the Push hardware is optimized solely for handling user input from the pads and buttons. So although Qt is used as the display technology on Push, it is not actually running on the device. When Live and Push are used together, Live starts another process which is responsible for rendering all of the content shown on the Push screen.

This architecture forces a strong implementation of the Model-View-ViewModel pattern. MVVM emphasises division of the lowest level of the data representation, the Model, from the representation which is intended to appear in a View, that is ‘the model of the view’, aka the ViewModel. Using QObjects with signalling functionality for the ViewModel, and using the same system for the View in QML, gives a high level of compatibility between the components of the design.

The Data Model – the values of parameters, and the content of a song – of what is shown on Push is defined in the Live 9.5 process and then shared via an IPC channel with the Push display process using a JSON protocol. The Push display process creates a ViewModel – QObjects with properties representing what should be shown on screen – making it available in the context of a QML engine, which
then defines the View for the Push screen. The rendered pixels are transformed to the pixel format expected by the hardware and then transferred over USB to Push.

On Push

What were the biggest benefits of using Qt for Push?

We evaluated several GUI technologies when starting work on Push, such as HTML and JUCE. Qt stands out mainly for the QML language, the QtQuick technology, the Scene Graph API and easy integration with OpenGL.

The obvious advantages of the QML language for rapid prototyping have really stood out for us, as well as the ability to extend it with plugins written in C++. Qt contains a broad range of ready-to-use APIs which we wouldn’t have access to if we had written the UI in HTML, for example. We try to make sure we make full use of all Qt/QML functionality that is appropriate for us, and keep an eye on new releases to see what becomes available.

How did the team take the new tools? How was the learning curve?

Initially a small task force investigated the GUI technologies available and when Qt was selected for Push, that task force began sharing their knowledge with the rest of the team. From that point, we have heavily relied on the invaluable Qt documentation.

The Qt blog is also an important resource, because articles there often display a more philosophical approach to how to write QML. While the Qt Forum or Stack Overflow can be a useful resource for QML beginners on how to get specific things done with available APIs, they often don’t provide principles and details about the mindset required to write and design declaratively with QML.

Writing QML code as a beginner is relatively easy. Trying things is cheap and easy and it results in very fast feedback because of the interpreted nature of the language. However, figuring things out as we go does not always lead to the best design. So a more interesting topic is ‘how difficult is it to do QML right as a beginner?’.

There are certain traps that we found, such as over-use of procedural code like onFooChanged to try to enforce a particular order of operations. It is better to encapsulate tolerance of indeterminate order of operations in a declarative interface, but learning the details of exactly how to do that and how to recognise the traps before we fall into them (or create new ones) is something that comes only with experience in the real world!

Developers new to QML need to learn a different approach to programming which is declarative instead of imperative, and where things can change ‘spontaneously’ or in an unexpected order. As we grow the team working on Push here at Ableton, new developers might leave QML to others because of caution about ‘doing it right’, or worrying that ‘there must be a better way’.

We are extending our best practices on how to write QML code and how to interface it with non-Qt code as time goes on, so we have accumulated some good guidelines now.

Were there technical challenges in getting the remote screen to work properly?

The technical separation of the user interface from the screen requires that we implement an unusually rigorous MVC pattern. The screen is really just a View and it doesn’t have any way to offer user interaction. There is no way to take convenient shortcuts on the hardware directly in response to a user interaction.

That separation means there are no GUI events handled in QML at all such as mouse, keyboard, push of a button or press of a pad. The View for Push is simply a declarative response to ViewModel updates received from Live, so changes are represented as ‘this is now the selected track’ rather than ‘this track was just clicked’.

However, user interaction hints do sometimes need to be part of the communication with the display process. For example, a single long list of items is broken up into a multi-column list. Changes of the ‘currently highlighted item’ are animated vertically through the adjacent column when the user scrolls.

The user can also use directional buttons on the hardware to change selection horizontally, and that calls for horizontal animation. So, it is not enough to update the ViewModel with the information that the selected item is now ‘My Heart Will Go On’. The information about whether that is the result of horizontal or vertical movement must also be conveyed in the protocol.

How about timing? Music making is real time, how does it all fit together?

The parts of Live that concern playback of music run in a separate thread to the UI, so that operations that can stall the Live UI, such as loading a large drum rack, do not stall the sound playback.

The process separation for the Push display process is an extension of this isolation from expensive operations in Live, in a sense. If Live is stalled in an expensive operation, the Push display process remains responsive. It is not possible to have multiple independent GUI threads with Qt, so the multi-process solution is the next best thing. We did, in an early iteration, attempt to combine the event loop used in Live with the Qt event loop. Qt APIs made the integration possible, but it seemed impossible to achieve our 60 fps target for the Push GUI while the Live GUI shared the same 16 ms time slices.

In fact, there is another level of separation in the architecture for real-time GUI updates. The IPC mechanism described previously is used only for updates to the song definition and user interface events. Real-time information such as the playhead progress uses a separate channel between the Live engine thread and the Push display process, so it even bypasses the Live GUI thread entirely. This
channel contains much lower traffic and so the display on Push for the playhead more accurately reflects real-time information.

Did you find any other benefits of QML when creating the Push interface?

One of the impressive things about QML is how animations work and how easy they are to use. There is something slightly magical about them. They’re so smooth and easy to add that we are not afraid of adding them – our designers sometimes have to restrain us!

Because our QML doesn’t deal with user input events, the View is often heavier than it needs to be. Reusable generic widgets, such as Button, usually implement some form of mouse and keyboard handling which we don’t need. Using primitives such as Rectangles may be an option to avoid the weight of Button features that are not used, but there are extra features in Button which we do use, such as text that fades out towards the edge and consistent styling. Additionally, we want to reuse code as far as possible. These concerns make it worthwhile to use the Button instead of a simpler alternative.

Any future plans on Push that you can share?

We are always looking for opportunities to develop our products, but I’m afraid we can’t give information about future plans. As any product developer knows: things can change!

Thank you for sharing your experiences with Qt and QML on the Push. It really is an amazing piece of music hardware.

Thank you! We are very proud of Push and what it enables musicians to create. Thank you too, for taking the time to conduct this interview.

The post Ableton Push – Qt in music making appeared first on Qt Blog.



Source :- Qt Blog http://ift.tt/1YheHKn

How to accelerate your embedded development

Over the last couple of years, I have been working on helping embedded device creators accelerate their embedded device development strategy. I’ve seen the challenges product managers face and we’ve worked together to find solutions that have enabled them to reduce their overhead, future-proof their platform and their strategy.

We see that unlike smartphones, which sells in millions, most embedded products such as ECG machines, PoS machines, Laboratory and Test equipment, Ticket vending machines, etc. have low sales volume. Furthermore, the product life of embedded devices ranges to 7+ years in contrast to the 15-18 months life for smartphones. Due to this limited sales volume and long product life, custom or chip-based development of embedded devices adds significant overheads in terms of supply chain inefficiencies, platform obsolescence, non-optimal cost structure, and barriers to adopt latest technologies. Read more on this, here.

Our team at Toradex, see opportunities of how you can leverage the synergies between such a platform as Toradex and a development framework like Qt to accelerate your product development.

A key starting aspect of this is to choose a compact platform that offers application-agnostic hardware and software. Irrespective of whether you are building a ECG machine or a home-automation device, the application-agnostic part remains same. I believe that OEMs and system designers should focus more on enhancing end-user experience and product differentiation, rather than spending effort on essential design commodities. By using an off-the-shelf platform like our System on Module (SOM), a.k.a. Computer on Module (COM), you can easily reduce your time-to-market by 8-10 months along with reduction in development cost and risk.

toradex soctoradex_carrier_board

Addressing supply chain inefficiencies

Component obsolescence leads to platform redesign and in turn, adds cost and resource effort. Finding a platform vendor that engages in large volume business with the leading SoC and memory vendors in the market will quickly reduce your costs, as the former gets better pricing deals. We do this for you at Toradex. We also mitigate the risk of component obsolescence with guaranteed SOM availability for more than 10 years.

Mitigating platform obsolescence

With Moore’s Law in action, the silicon components keep on maturing with smaller size, power efficiency and lower price. Customers’ demands for high performance and power-efficient products leads to frequent redesigns of the platform to accommodate latest technologies. However, such redesigns add to cost, thus compromise profits. With our pin-compatible SOMs, for example, upgrading a platform is as easy as plug-and-play. New SOMs can be attached to existing carrier boards with very less software changes. Thus, your platform remains future-proof.

Amortizing high NRE cost

Embedded product development involves high NRE cost. The high NRE cost is amortized over low sales volume, thus leading to non-optimal cost structure for the OEMs. Consequently, it’s imperative that you finds ways to reduce your development risk and decrease development time. You can achieve this by using an off-the-shelf platform, which is optimized for power efficiency and performance. At Toradex, we do this by carrying out in-house development of hardware and software. Our platforms are stress-tested in field conditions by numerous existing customers, resulting in a robust and mature platform. This way your project is mostly limited to application development and integration, thus shrinking the NRE cost.

Avoiding barriers to adopt latest technologies

SOM vendors enable the penetration of leading technologies in embedded market, by engaging with market leaders of processors. Usually, leading SoC vendors prefer high volume businesses. Toradex offers SOMs based on leading processors: Freescale® Vybrid™, Freescale® i.MX 6 and NVIDIA® Tegra™. A new SOM based on Freescale® i.MX 7 will be available by Q1 2016.

Bringing this all together

Toradex pursues direct online sales with publicly disclosed pricing. We have local warehouses that guarantees ex-stock supply, along with in-house hardware and software development. We provide free tools and libraries including Qt of course, 10+ years product availability, and then to wrap it all up we offer free support in local language by the developers. More info on this, here

Toradex SOM and Qt

I spoke earlier of the importance of the application-agnostic part of your product by providing a scalable and compact platform. (You can easily get a compatible carrier board as per your application’s requirement, here.) Then comes the application software. Build your application using the awesome and exciting features of Qt. Qt is easily used on Toradex SOMs with our Apalis iMX6, Colibri iMX6, and Colibri VF61 & VF50 among the reference platforms available for Qt for Device Creation.

Want to learn more?

Let’s talk about how we at Toradex can help you in your next product development. Contact us here:  support.arm@toradex.com

 

About the Guest Blogger: Prakash has over a decade of experience in engineering and marketing roles in the embedded industry and is currently a Product Manager at Toradex. He is passionate about exploring avenues on how to build products cost-effectively, without compromising on end-user experience.

The post How to accelerate your embedded development appeared first on Qt Blog.



Source :- Qt Blog http://ift.tt/1NfJl1t